PQO: Defining a PQO network

Overview

A Parallel Query Option/204 network must be defined before any PQO application can run successfully.

The Model 204 system manager defines the PQO network configuration and protocols to Model 204. The network systems programmer sets up the SNA Communications Server definitions, if you are using an SNA Communications Server for the network.

Finally, the Model 204 system manager sets Model 204 Online environment parameters that are required for PQO.

Once the network is properly defined, its operation is transparent to the SOUL application programmers.

Network configuration

The PQO network connects two or more copies of Model 204. The Model 204 copies can be on the same physical machine or not, and they can be in the same operating system or not. The copies communicate through TCP/IP or SNA Communications Server over the communications network. Both network types use the LU 6.2 interface services of the Model 204 Horizon facility.

Each copy of Model 204 opens links that are either SNA logical units or TCP/IP ports, and provides network access and services to its PQO partners. Each node can accommodate two types of functions, or processes, in Horizon terminology:

This process...	Performs only this action...
Client	Queries partner databases
Server	Replies to database queries

These are companion processes, paired in the network. A client on one node initiates a conversation requesting access to a remote file. The corresponding server on another node responds to the request.

In the PQO topics, a node is often referred to in terms of the type of network process that is active--a client node is the node on which the client program being referred to is defined.

The Basic network configuration figure shows the physical configuration of a PQO network with one client and one server. The direction of the control flow arrow shows the path of a request for remote data in the PQO network where communication is initiated by the client. The path is reversed when the data is returned.

Network characteristics:

• Two or more nodes: one is client; one or more are servers
• Two-way path, when links are activated
• Communication initiated by client
• Optional use of APSY subsystems

Basic network configuration

The previous figure illustrates a client/server relationship between two Onlines. An Online may be configured as a client of any server Online and at the same time as a server for any other client Online.

Interrelated network elements

Certain parameters in the Model 204 and the network definitions must be set in relation to one another, as described in the sections that follow. Because the definitions are mutually dependent, you might have syntactically valid definitions that are not compatible. Such an error is not detected until you first try to open a remote file.

The following table summarizes these interrelated elements for TCP/IP service.

Interrelated components of a PQO network for TCP/IP service

Model 204
DEFINE LINK	DEFINE PROCESS-GROUP	DEFINE PROCESS	Model 204 Online
Each link requires a SERVPORT specifying the port number for this connection. LOCALID must specify the dotted decimal address of the TCP/IP on this operating system	REMOTEID applid must match LOCALID name on remote LINK definition.
CONNECTIONS sets maximum number of concurrent sessions, plus two, for a minimum of 50.
	For a server, use MASK to limit the range of addresses that can connect to this port. For a client, use PORT to specify the port of the server, which must match SERVPORT of the server's DEFINE LINK.
Link definition name identifies connection	LINK parameter name matches DEFINE LINK name
	Processgroup definition name identifies group	DESTINATION or FROM name matches defined processgroup name
	LOGIN=TRUST specifies password not required		SYSOPT includes X`10' to require login (server system)
	INLIMIT sets maximum number of concurrent inbound conversations (server)		NOTERM sets maximum number of threads for inbound conversations (server)

The following table summarizes these interrelated elements for SNA Communications Server service. Only those items that have a corresponding element in a related definition are shown in the table.

Interrelated components of a PQO network for SNA Communications Server

SNA		Model 204
Mode table	APPL statement	DEFINE LINK	DEFINE PROCESSGROUP	DEFINE PROCESS	Model 204 Online
	One APPL for each link Label identifies LU application node	Each link requires an APPL LOCALID name must match APPL label	REMOTEID applid must match LOCALID name on remote LU
	PARSESS=YES enables support for concurrent sessions	SESSIONS sets maximum number of concurrent sessions
	PRTCT specifies password	PSWD enables password protection
		Link definition name identifies connection	LINK parameter name matches DEFINE LINK name
			Processgroup definition name identifies group	DESTINATION or FROM name matches defined processgroup name
			LOGIN=TRUST specifies password not required		SYSOPT includes X`10' to require login (server system)
			INLIMIT sets maximum number of concurrent inbound conversations (server)		NOTERM sets maximum number of threads for inbound conversations (server)
LU 6.2 mode table for Model 204	MODETAB specifies LU 6.2 table DLOGMOD specifies entry in table (optional)		MODENAME specifies entry in mode table (optional)

PQO DEFINE commands

For z/OS and z/VSE systems, TCP/IP may be used instead of SNA Communication Server. The discussion in this chapter will point out where and how you must define either type of network. You can also refer to DEFINE LINK command: Horizon for TCP/IP.

For each copy of Model 204 in the PQO network, you must define three types of entities for each client or server application: a link, a processgroup, and a process. These entities and their interdependencies form the network's logical layer.

In addition, some of the network entity definition parameters must be set relative to the SNA Communications Server network definition.

The PQO network definitions are closely parallel to those of Horizon, which are described in Horizon network management. This section presents the PQO DEFINE command syntax and describes the parameter specifications that are modified or otherwise different from the standard Horizon definitions. Examples of sample PQO network definitions are provided in Two-node network example and in PQO: Three-node network example.

Using the DEFINE LINK command

The DEFINE LINK command requirements have differing resource parameters for TCP/IP or SNA, so the syntax for each varies a bit. In general TCP/IP and SNA supply the following link definition:

• Specifies a name that identifies the Model 204 node to the SNA network
• Defines the physical communications transmission method (TRANSPORT) and the logical conversation rules (PROTOCOL)
• Specifies resource parameters, which differ for TCP/IP and SNA. For example, for TCP/IP, CONNECTIONS replaces SESSIONS for SNA. Use the DEFINE LINK command syntax suitable for your site.

Although a single link can be shared by both PQO and Horizon conversations, for performance reasons, Technical Support recommends against sharing links.

A connection request for a link can succeed only if an OPEN LINK command has opened the link. For more information about OPEN LINK, see PQO: Managing the PQO network.

DEFINE LINK command for TCP/IP

The TCP/IP-specific PQO syntax of the DEFINE LINK command is:

Syntax

DEFINE LINK name [LIKE previousname] WITH - SCOPE=SYSTEM - PROTOCOL=IP - TRANSPORT={TCPSE | TCPVSE} - CONNECTIONS=nnnn - INBUFSIZE=nn - LOCALID={address | ANY} - SERVPORT=nnnnn

Parameters

PQO-specific comments and recommendations for TCP/IP service follow:

• PROTOCOL=IP is required and specifies the set of rules (SNA LU 6.2 on a TCP/IP link) used to control communications.
• TRANSPORT must be set to TCPSE (for z/OS) or TCPVSE (for z/VSE).
• CONNECTIONS is required and specifies the maximum number of concurrent connections that can be activated for the link, plus two. A connection is activated when a conversation is initiated. For PQO with TCP/IP service, a starting value of 50 is recommended with adjustment upward as necessary to accommodate actual network traffic. See Usage notes on IODEV=51 for information about the relationship between the number of connections, the number of server threads, and the number of remote users who can access remote files on a particular node.
• INBUFSIZE is required and specifies the size of the buffer allocated for the TCP/IP data transfer for each conversation. Technical Support recommends that you set this to at least 4096, for efficiency.
• LOCALID is required and specifies the TCP/IP address that identifies this system.
• SERVPORT must be set to a port number greater than 4096 and unique for this link. It must match the PORT parameter of the DEFINE PROCESSGROUP command of the client system.

DEFINE LINK command for an SNA network

The PQO syntax of the DEFINE LINK command for SNA network is as follows.

Syntax

DEFINE LINK name [LIKE previousname] WITH - SCOPE=SYSTEM - TRANSPORT=VTAM - PROTOCOL=LU62 - SESSIONS=nn - INBUFSIZE=nn - LOCALID=applid - [PSWD | NOPSWD]

Required for z/VM only:

GCSID=vmid

Parameters

PQO-specific comments and recommendations for SNA service follow:

• PROTOCOL=LU62 is required and specifies the set of rules (SNA LU 6.2) used to control communications.
• SESSIONS is required and specifies the maximum number of concurrent sessions, or connections between logical units, that can be activated for the link. A session is activated when a conversation is initiated. For PQO, a starting value of 3 is recommended with adjustment as necessary to accommodate actual network traffic. See Usage notes on IODEV=51 for information about the relationship between the number of sessions, the number of server threads, and the number of remote users who can access remote files on a particular node.
• INBUFSIZE is required and specifies the size of the buffer allocated for the receive-any operation for the initial SNA Communications Server Request Unit (RU) of each inbound conversation. Set INBUFSIZE to the same value as the SNA Communications Server logmode parameter RUSIZES (whose recommended setting for PQO is 2K). For more information about RUSIZES, see Horizon network management.
• LOCALID is required and specifies the LU name that identifies this Model 204 application node to the SNA network. The LOCALID must match the name in the SNA Communications Server APPL network definition. See Coding the APPL statements for the SNA Communications Server network for a description of the APPL name definition.

Using the DEFINE PROCESSGROUP command

The DEFINE PROCESSGROUP command:

• Groups processes according to certain attributes, such as the maximum number of concurrent conversations, to facilitate resource allocation by applications
• Connects processes associated with each named group to a specific link
• Specifies a remote node with which the associated processes can communicate
• Provides a pool of sessions to be used by multiple processes

A Model 204 site can use different processgroup definitions to segregate groups of processes, for example, to isolate groups that participate in PQO network processing from Horizon network groups.

A single processgroup definition can be used by both PQO and Horizon conversations.

DEFINE PROCESSGROUP command for TCP/IP service

The PQO syntax of the DEFINE PROCESSGROUP command for TCP/IP service is:

Syntax

DEFINE PROCESSGROUP name [LIKE previousname] WITH - SCOPE=SYSTEM - LINK=linkname - REMOTEID=address - INLIMIT={nnnn | 0} PORT=nnnnn GUESTUSE={ACCEPT | REJECT} LOGIN={TRUST | NOTRUST} MASK={dotted-decimal | 255.255.255.255}

Parameters

PQO-specific comments and recommendations for TCP/IP service follow:

• name is used on DEFINE PROCESS commands to refer to this processgroup. The length of the name must be eight characters or fewer. ALL is a reserved word and cannot be used.
• LINK is required and associates the group with a locally defined link that implies the transport type and conversation protocol. linkname must match the name used in a local DEFINE LINK command.
• REMOTEID is required and identifies the remote TCP/IP system with which the group communicates. It must match the LOCALID parameter specified in the DEFINE LINK command at the remote node.
• INLIMIT=nnnn and NOINLIMIT are mutually exclusive options that control the allocation of conversations with the server. INLIMIT sets the maximum number of client requests for conversations with a server. To ensure that there are enough service threads to handle these requests, specify an appropriate value for the IODEV line parameter NOTERM (see Specifying IODEVs for PQO service threads). NOINLIMIT or a nonzero INLIMIT value is required for the server in PQO. Specifying NOINLIMIT is equivalent to specifying 32767; that is, as many as 32,767 concurrent connections are allowed.
• OUTLIMIT=nnn and NOOUTLIMIT are mutually exclusive options that control the allocation of conversations with the client. NOOUTLIMIT or a nonzero OUTLIMIT value is required for the client in PQO.
• PORT is required for the client system and specifies the remote server port (SERVPORT) with which the client will establish a conversation. PORT is not required in the DEFINE PROCESSGROUP command of the service Online, unless that Online is also a client to another server.
• LOGIN indicates whether the local server process requires a password from the remote client process at OPEN FILE time. Since there is no facility for handling a password in PQO, TRUST is the required value for LOGIN. The CCAD2S process logs in the incoming client user without a password and assigns privileges from either the CCASTAT password table or an external security package. The client user ID must be specified in CCASTAT or in a security package on the server. Both client and server must specify LOGIN=TRUST.
• MASK is used to limit the range of remote network addresses that may connect to this system. MASK is used with REMOTEID to identify a range of remote addresses that may connect to this server system. For example, a REMOTEID of 12.120.0.0 and a MASK of 255.255.0.0 will prevent connections from any network address that does not begin with 12.120. However, the last two bytes of the remote dotted decimal address in this example can be any value, because the MASK has not selected this part of the address for comparison.

DEFINE PROCESSGROUP command for SNA service

The PQO syntax of the DEFINE PROCESSGROUP command is:

Syntax

DEFINE PROCESSGROUP name [LIKE previousname] WITH - SCOPE=SYSTEM - LINK=linkname - REMOTEID=applid - LOGIN=TRUST

Optional parameters:

INLIMIT=nnnn | NOINLIMIT OUTLIMIT=nnnn | NOOUTLIMIT RETAIN=nnnn | RETAINALL MODENAME=modeentry GUESTUSE={ACCEPT | REJECT}

Parameters

PQO-specific comments and recommendations for SNA service follow:

• LINK is required and associates the group with a locally defined link that implies the transport type and conversation protocol. linkname must match the name used in a local DEFINE LINK command.
• REMOTEID is required and identifies the remote node with which the group communicates. The applid value, the SNA Communications Server APPL definition name of the remote node, must match the LOCALID parameter specified in the DEFINE LINK command at the remote node.
• LOGIN indicates whether the local server process requires a password from the remote client process at OPEN FILE time. Since there is no facility for handling a password in PQO, TRUST is the required value for LOGIN.
The CCAD2S process logs in the incoming client user without a password and assigns privileges from either the CCASTAT password table or an external security package. The client user ID must be specified in CCASTAT or in a security package on the server. Both client and server must specify LOGIN=TRUST.
• INLIMIT=nnnn and NOINLIMIT are mutually exclusive options that control the allocation of conversations with the server. INLIMIT sets the maximum number of client requests for conversations with a server. To ensure that there are enough service threads to handle these requests, specify an appropriate value for the IODEV line parameter NOTERM. NOINLIMIT or a nonzero INLIMIT value is required for the server in PQO.
• OUTLIMIT=nnnn and NOOUTLIMIT are mutually exclusive options that control the allocation of conversations with the client. NOOUTLIMIT or a nonzero OUTLIMIT value is required for the client in PQO.
• MODENAME is optional and specifies a particular entry in the SNA Communications Server mode table to be used when a SNA Communications Server session is established for an outbound conversation. For information about the SNA Communications Server mode table, see the MODETAB parameter description.
• GUESTUSER depends on whether and/or which you have a third-party external security package installed for Model 204.
  • GUESTUSER=ACCEPT is required for PQO when RACF or TOP SECRET is installed.
  • GUESTUSER=REJECT, the default, is required for PQO when CA-ACF2 is installed.

Using the DEFINE PROCESS command

There are two distinct types of PQO processes: client and server. The client process, CCAD2C, is the network entity that initiates a conversation. The server process, CCAD2S, accepts a remote communications request.

The DEFINE PROCESS command syntax is the same for TCP/IP and SNA.

The DEFINE PROCESS command associates the process name with one or multiple processgroups, each of which associates it with a link.

DEFINE PROCESS command for either TCP/IP or SNA service

The PQO syntax of the DEFINE PROCESS command is:

Syntax

DEFINE PROCESS {CCAD2C | CCAD2S} [LIKE previousname] WITH SCOPE=SYSTEM [TIMEOUT=nnnn]

Required for the CCAD2C client process:

DESTINATION=(pg1,sym1 [,pg2,sym2] ...)

Required for the CCAD2S server process:

FROM= {processgroup | (pg1 [,pg2] ...)}

Client process DESTINATION parameter

The DESTINATION parameter is required for the CCAD2C client process. DESTINATION associates the process with a locally defined processgroup or set of processgroups.

DESTINATION is specified as a list of processgroups with associated symbolic names.

DESTINATION=(pg1,sym1 [,pg2,sym2] ...)

where:

• pg1 and pg2 specify the names of the local processgroups with which the client process is associated.
• sym1 and sym2 are symbolic names, each from 1-8 characters in length. Each symbolic name is associated with the corresponding processgroup name in the pair. A symbolic name defined here is used with AT in a remote file specification to refer to a processgroup that is associated with a particular remote location. Specifying a remote file describes how symbolic location names are used to reference a remote file.

Each processgroup must be paired with a symbolic name, and vice versa. If not, the DEFINE PROCESS command is rejected or the opening of remote files fail. See PQO: Three-node network example for examples of DESTINATION parameter settings.

Server process FROM parameter

The FROM parameter is required for the CCAD2S server process and associates it with a locally defined processgroup or set of processgroups. The FROM parameter can be specified as either a single processgroup or as a list of processgroups:

FROM={processgroup | (pg1 [,pg2] ...)}

where:

• processgroup specifies the name of a local processgroup with which the server process is associated.
• pg1 and pg2 specify the names of the local processgroups with which the server process is associated.

See PQO: Three-node network example for examples of FROM parameter settings.

Client and server TIMEOUT parameter

TIMEOUT sets the time in seconds a process waits for a network transmission to arrive from a partner. If the TIMEOUT limit is exceeded, the connection is abnormally terminated. A PQO server process is likely often to be in protracted waiting states (wait type 27) while clients process the data the server has just sent.

Therefore, if you set the TIMEOUT value in a CCAD2S definition, make sure it is sufficiently high to avoid frequent unintended timeouts. In agreement with the client system manager, you can accept the default, TIMEOUT=0 (no server timeout) for the CCAD2S definition and rely on the client to provide terminal timeout checking with the Model 204 CCAIN TIMEOUT.

Runtime and user environment definition

In addition to specifying the network definitions, it is necessary to set up the Model 204 Online environment to support the PQO network. This section describes how to set the Model 204 environment parameters in the CCAIN input stream for PQO.

The parameters listed in the following table and described in this section are required in the client Online, the server Online, or both to support the PQO network.

CCAIN parameters required for PQO

Parameter	Required on client?	Required on server?
LOCATION	Yes	Yes
NRMTFILE	Yes	No
NRMTLOCS	Yes	No
NSUBTKS	Yes	Yes
IODEV	No	Yes

In addition to these parameters, you need to make sure that your settings are correct for Model 204 storage requirements and for the following Model 204 parameters:

FIXSIZE LFTBL, LQTBL, LRTBL, LSTBL, LVTBL MINBUF SPCORE

Setting the LOCATION parameter

The LOCATION parameter is a Model 204 User 0 parameter required for both clients and servers. It identifies the Model 204 copy as a remote application site within the PQO network.

The syntax of the LOCATION parameter is:

Syntax

LOCATION=name

where:

name is required and specifies the locally known name of the PQO network node. The name is a unique value, from 1-8 characters in length.

The LOCATION parameter is used internally, is displayed to identify client users when a service thread issues a LOGWHO command, and is used with BUMP SUBSYSTEM, MONITOR SUBSYSTEM, and STOP SUBSYSTEM commands to identify a service subsystem by its associated client.

This LOCATION parameter value does not have to match the value specified for any DEFINE FILE command LOCATION parameter or for any remote file specification (filename AT location).

During the Online run, the current LOCATION parameter setting can be displayed on the screen using the VIEW command.

LOCATION is nonresettable. See PQO: Three-node network example for examples of LOCATION parameter settings.

Setting the NRMTFILE parameter

The NRMTFILE parameter is a Model 204 runtime parameter that is required for PQO clients. NRMTFILE determines the number of remote Model 204 files that can be open concurrently to users on the client system.

The syntax of the NRMTFILE parameter is:

Syntax

NRMTFILE=nnnnn

where:

nnnnn is a numeric value that specifies the maximum number of remote file save areas allocated by Model 204 for the client. For PQO, the value must be at least one (for the client) in order to access remote files. The maximum value is 16383. The default NRMTFILE value is zero.

A nonzero setting of NRMTFILE is required in the User 0 parameter line of all Onlines that access remote files (all PQO clients). It is not required in an Online that is exclusively a server.

During an Online run, the current NRMTFILE parameter setting can be displayed on the screen using the VIEW command. See PQO: Managing the PQO network for a description of network monitoring commands.

NRMTFILE is nonresettable. See PQO: Three-node network example for examples of NRMTFILE parameter settings.

NRMTFILE functions like the NFILES parameter, except that NFILES allocates file save areas for local files.

Setting the NRMTLOCS parameter

The NRMTLOCS parameter is a Model 204 runtime parameter that is required for PQO clients. NRMTLOCS specifies the number of remote nodes that can be accessed by client users.

The syntax of the NRMTLOCS parameter is:

Syntax

NRMTLOCS=nnnnn

where:

nnnnn is a number from 0 to 2040. The default is 0.

A nonzero setting of NRMTLOCS is required in the User 0 parameter line of all Onlines that access remote nodes (all PQO clients). It is not required in an Online that is exclusively a server.

NRMTLOCS is nonresettable. During an Online run, you can display the current NRMTLOCS setting using the VIEW command.

Setting the NSUBTKS parameter

The NSUBTKS parameter is required for LU 6.2 pseudo subtasks. The syntax of the NSUBTKS parameter is:

NSUBTKS=nnnnn

Where:

nnnnn is a number value that specifies the maximum number of pseudo subtasks that can be used in a Model 204 run. For PQO, this number must be increased by two per link if running under z/OS, or by four per link if running under z/VM.

For performance reasons, Horizon and PQO conversations should not share links. However, if the NSUBTKS parameter was previously increased for Horizon links and the PQO network is sharing link definitions with Horizon, it is not necessary to increase NSUBTKS for PQO.

NSUBTKS is located in the User  0 parameter line in the client and server Onlines.

Specifying IODEVs for PQO service threads

In PQO, the server application processes the file locally and sends the data back to the client. The server's Online must provide the PQO service threads, which are defined by a particular class of IODEV statements, to process client requests.

Each IODEV=51 line in a server Online CCAIN stream defines a PQO service thread. You must determine the number of IODEV=51 lines in each server Online that optimally service your client demand.

The syntax of the IODEV parameter line is:

Syntax

IODEV=51,NOTERM=nn

Where:

• IODEV=51 is the required user parameter in the CCAIN for the PQO server Online. Each IODEV statement defines a Model 204 user. The total number of IODEV=51 lines determines the maximum number of PQO server applications that can run concurrently.
• NOTERM is a parameter that is required on the first user parameter line that specifies IODEV=51. The nn value specified indicates the total number of threads allocated for PQO inbound conversations in the server's Online. Setting NOTERM close to the total of INLIMIT parameter values on the DEFINE PROCESSGROUP commands for the server system avoids a shortage of PQO inbound threads so that all incoming conversation requests can be processed. See DEFINE PROCESSGROUP command for SNA service for a description of the INLIMIT parameter.

See PQO: Three-node network example for examples of IODEV statements for PQO.

Usage notes on IODEV=51

• IODEV=51 threads are required for a Model 204 Online only if it supports PQO server applications. A client is supported by its local user threads and requires no additional IODEV statements unless it also functions as a server.
• The number of IODEV=51 statements limits the server threads only. In a Model 204 Online supporting both client and server applications, the number of IODEV=51 statements does not affect the number of concurrent conversations that a client can initiate on other remote systems.
• A server Online allocates one IODEV=51 thread for each client user that opens a server file or files. That thread services all the user's requests of that Online. When a client closes its last open file on a server node, the service thread is logged out and made available for another client user.
• When a client is using an IODEV=51 thread, the USERID parameter of the service thread is set to the USERID value of the client Horizon thread. USERID must be specified in CCASTAT or external authorizers such as ACF2, but it is not validated by a password. Client users are not prompted for passwords.
• A Model 204 Online has a pool of IODEV=51 threads to share among all nodes requesting access to files owned by that Online. The number of remote users who can access files on a given node is limited by the number of sessions that can be bound to the service node (the size of the pool) and the number of service threads (NOTERM) that are allocated in the server Online IODEV statement. There is no way to explicitly allocate a particular number of service threads to one or more specific client nodes. This capability is implicitly provided through the processgroup entity (see Using the DEFINE PROCESSGROUP command).

SNA Communications Server network definition

PQO communicates over an SNA network through SNA Communications Server by using the LU 6.2 interface of the Model 204 Horizon facility. For z/OS and z/VSE systems, PQO can alternatively communicate using TCP/IP, although this still uses Horizon. See below for an example.

SNA Communications Server communications support must be in place to use PQO. This section describes how to set up the SNA Communications Server network definition with parameters that correspond correctly to the Model 204 network definitions.

The SNA Communications Server setup is similar to that required for Horizon without PQO. See Horizon network management for information about SNA Communications Server network support for Horizon. Basic network configuration, above, shows the basic PQO communications pathway.

Components of SNA Communications Server definition

The host copies of Model 204 used in PQO host-to-host communications are SNA Communications Server application nodes. In a PQO session, both partners (client and server) are SNA Communications Server application LUs.

The SNA Communications Server network definition for PQO includes:

• APPL (application) statement (for each PQO link)
• Mode table (for LU 6.2 session parameters for the network)

The following figure shows the basic components of the SNA Communications Server definition for PQO. The PQO network shares the existing LU 6.2 table definition (shown as mode table LU62 in the diagram) with the Horizon facility.

Components of the SNA Communications Server definition for PQO

The previous figure illustrates a SNA Communications Server definition for two application nodes, one for non-PQO Horizon communications (HZN) and one for Parallel Query Option/204 (PQO). The LU 6.2 mode table shown (LU62) contains a single entry (M204) for Model 204 network session parameters.

Coding the APPL statements for the SNA Communications Server network

In an SNA Communications Server network a separate APPL statement is required for each PQO link entity defined with a Model 204 DEFINE LINK command.

There are three parameters that you must specify in the APPL statement to define SNA Communications Server support for PQO link entities. In addition, there are three optional parameters that you can specify. Other parameters exist for the APPL statement but, because they default to values appropriate for PQO communications, they are not mentioned here.

The required and optional parameters of the APPL statement used for PQO are shown in the following syntax. These parameter settings are the same as those recommended for typical Horizon connections in APPL statement parameters. Only the MODETAB parameter for PQO requires additional comment.

Syntax

name APPL AUTH=ACQ, PARSESS=YES, MODETAB=tablename, Optional: DLOGMOD=entryname, VPACING=5, PRTCT=password

Notes on MODETAB: MODETAB is a required parameter. It ties the APPL definition to the mode definition that specifies the particular set of SNA protocols required for the LU 6.2 session between two PQO LUs.

Since PQO uses Horizon protocols, no new table is created for the LU 6.2 session parameters. The MODETAB name for PQO must match the name of the mode table used by the Horizon facility. See the LU 6.2 mode table example.

Setting session parameters

The set of LU 6.2 session parameters (the mode definition) required for PQO is stored in a mode table for each LU. The server LU's APPL definition points to the mode table, as is done in Horizon.

In PQO communications, the client LU acts as the primary partner in the conversation. The client LU initiates a conversation and acquires a session with the secondary partner, the server LU. The LU 6.2 session parameters are obtained by the client LU from the entry defined for the server, and are then sent to the partner server LU in the BIND message that establishes the session. The client and server LUs share the common set of LU 6.2 rules required to govern the session.

Each PQO link entity supports multiple sessions. A single link entity that supports both client and server processes can act as the primary role partner, or client, on one session and as the secondary role partner, or server, on another session.

The mode table showing the basic set of LU 6.2 session parameters recommended for both Horizon and PQO is shown in the following example.

See the Notes on MODETAB for a description of the APPL parameter used to reference this table.

See Horizon network management for more information about APPL; specifically, see Modifications for specific systems and applications for details about modifying the mode table parameters such as RUSIZES and SSNDPAC.

Mode table example

table name MODETAB entry name MODEENT LOGMODE=entryname TYPE=X'00', FMPROF=X'13', TSTPROF=X'07', PRIPROT=X'B0', SECPROT=X'B0', COMPROT=X'50B1', RUSIZES=X'8888', SSNDPAC=X'05', PSERVIC=X'060200000000000000102000' . . (additional table entries, if specified) . table name MODEEND

Two-node network example

This section provides sample network definitions for PQO including:

• Model 204 DEFINE commands
• Runtime and user environment parameters
• SNA Communications Server APPL statements, as needed

The sample PQO network supports a Model 204 reporting application for an insurance company requiring communication between two offices in the Boston area. The downtown office produces a policy report using data files from the suburban office.

Each office system operates independently running under its own version of Model 204 in an z/OS environment. The downtown office (Boston1) is the client in the network, requesting information, and the suburban office (Boston2) is the server, providing access to files.

Comparing network types

There are examples below for SNA Communications Server and for TCP/IP. For TCP/IP systems the User 0 parameters and the DEFINE PROCESS parameters are the same, The DEFINE LINK and DEFINE PROCESSGROUP parameters are different as shown, and the APPL statements are not required.

Client input stream excerpt for SNA Communications Server network

//CCAIN DD * * User 0 parameters . . . NRMTFILE=4, NRMTLOCS=1, NSUBTKS=4, LOCATION=BOSTON1 . . . * Single link, single process network definition DEFINE LINK LINK1 WITH SCOPE=SYSTEM LOCALID=DISUSR01 - TRANSPORT=VTAM PROTOCOL=LU62 INBUFSIZE=512 - SESSIONS=4 DEFINE PROCESSGROUP PGRP1 WITH SCOPE=SYSTEM - LINK=LINK1 OUTLIMIT=48 INLIMIT=0 - REMOTEID=125.20.34.9 LOGIN=TRUST PORT=7001 */the SERVPORT value in service Online/* DEFINE PROCESS CCAD2C WITH SCOPE=SYSTEM - DESTINATION=(PGRP1,OFFICE1) . . . /*

Modifications for client input stream for TCP/IP network

The following DEFINE LINK and PROCESSGROUP definitions are for a TCP/IP system. The other elements in the client input stream remain the same as for the previous SNA Communications Server network.

DEFINE LINK LINK1 WITH SCOPE=SYSTEM - LOCALID=125.20.34.16 - TRANSPORT=TCPSE PROTOCOL=IP SERVPORT=7000 - INBUFSIZE=4096 - CONNECTIONS=50 DEFINE PROCESSGROUP PGRP1 WITH SCOPE=SYSTEM - LINK=LINK1 OUTLIMIT=48 INLIMIT=0 - REMOTEID=125.20.34.9 LOGIN=TRUST - PORT=7001

Server input stream excerpt for SNA Communications Server network

//CCAIN DD * * User 0 parameters . . . NSUBTKS=6, LOCATION=BOSTON2 * User parameter lines IODEV=51,NOTERM=4 IODEV=51 IODEV=51 IODEV=51 * Single link, single process network definition DEFINE LINK LINK2 WITH SCOPE=SYSTEM LOCALID=DISUSR02 - TRANSPORT=VTAM PROTOCOL=LU62 INBUFSIZE=512 - SESSIONS=4 DEFINE PROCESSGROUP PGRP2 WITH SCOPE=SYSTEM - LINK=LINK2 OUTLIMIT=0 INLIMIT=4 - REMOTEID=DISUSR01 LOGIN=TRUST DEFINE PROCESS CCAD2S WITH SCOPE=SYSTEM - FROM=PGRP2 . . . /*

Modifications for server input stream for TCP/IP network

The following DEFINE LINK and PROCESSGROUP definitions are for a TCP/IP system. The other elements in the server input stream remain the same as the previous SNA Communications Server network.

DEFINE LINK LINK2 WITH SCOPE=SYSTEM LOCALID=125.20.34.9 - TRANSPORT=TCPSE PROTOCOL=IP SERVPORT=7001 - INBUFSIZE=4096 - CONNECTIONS=50 DEFINE PROCESSGROUP PGRP1 WITH SCOPE=SYSTEM - LINK=LINK1 OUTLIMIT=0 INLIMIT=48 - REMOTEID=125.20.34.0 LOGIN=TRUST - MASK=255.255.255.0

APPL statements required for only SNA Communications Server network

Client APPL statement

The APPL statement for LINK1, coded in BOSTON1's VTAMLST data set, is:

DISUSR01 APPL AUTH=ACQ, PARSESS=YES, MODETAB=LU62, VPACING=5

Server APPL statement

The APPL statement for LINK2, coded in BOSTON2's VTAMLST data set, is:

DISUSR02 APPL AUTH=ACQ, PARSESS=YES, MODETAB=LU62, VPACING=5

See also

• PQO: Overview of Parallel Query Option/204
• PQO: Defining a PQO network
• PQO: Managing the PQO network
• PQO: Managing files and groups
• PQO: Remote files and scattered groups
• PQO: Scattered APSY subsystems
• PQO: Three-node network example