PQO: Managing the PQO network - Revision history

ELowell: /* Using the MONITOR command */

2016-02-05T00:27:47Z

Using the MONITOR command

← Older revision		Revision as of 00:27, 5 February 2016
Line 333:		Line 333:
	</table>		</table>
	<p>		<p>
	The MONITOR command for network entities operates the same for PQO as it does for the Horizon network. It requires User 0, system manager, or system administrator privileges~~. See the <var class="book">Rocket Model 204 Horizon: Intersystem Processing Guide</var> for more information about MONITOR for network entities~~.</p>		The MONITOR command for network entities operates the same for PQO as it does for the [[Horizon network management\|Horizon network]]. It requires User 0, system manager, or system administrator privileges.</p>
	<p>		<p>
	MONITOR SUBSYSTEM output reports whether subsystem members are optional or mandatory, and it has an option (FROM location) that allows PQO users to specify exactly the service subsystem monitored. Ordinary user privileges are required. </p>		MONITOR SUBSYSTEM output reports whether subsystem members are optional or mandatory, and it has an option (FROM location) that allows PQO users to specify exactly the service subsystem monitored. Ordinary user privileges are required. </p>

ELowell: /* Communications error display format */

2016-02-05T00:20:42Z

Communications error display format

← Older revision		Revision as of 00:20, 5 February 2016
Line 495:		Line 495:
	STATUSD is set to the return code that details the specific error condition within a particular STATUS category. </p>		STATUSD is set to the return code that details the specific error condition within a particular STATUS category. </p>
	<p>		<p>
	STATUS and STATUSD refer to the SOUL $STATUS and $STATUSD function values described in ~~the <var class="book">Rocket Model 204~~ Horizon~~: Intersystem Processing Guide</var>~~.</p>		STATUS and STATUSD refer to the SOUL $STATUS and $STATUSD function values described in [[Horizon conversation interface]].</p>

	===Using the status return codes===		===Using the status return codes===
	<p>		<p>

ELowell: /* Using the LU 6.2 network administration commands */

2016-02-05T00:18:35Z

Using the LU 6.2 network administration commands

← Older revision		Revision as of 00:18, 5 February 2016
Line 54:		Line 54:
	</table>		</table>
	<p>		<p>
	The Model 204 network administration commands require User 0, system manager, or system administrator privileges. See ~~the <var class="book">Rocket Model 204~~ Horizon~~: Intersystem Processing Guide</var>~~ for information about using the LU 6.2 network administration ~~commands. That volume serves as the primary reference for the~~ commands. </p>		The Model 204 network administration commands require User 0, system manager, or system administrator privileges. See [[Horizon network management]] for information about using the LU 6.2 network administration commands.</p>

	====Using the OPEN LINK command====		====Using the OPEN LINK command====
	<p>		<p>
	Use the OPEN LINK command to establish the connections for a PQO conversation. Both the link on the client and the corresponding link on the server must be opened before a client user can access remote server files. The syntax of the OPEN LINK command is the standard Horizon network OPEN LINK syntax. For information about using the OPEN LINK command, see ~~the <var class="book">Rocket Model 204~~ Horizon~~: Intersystem Processing Guide</var>~~.</p>		Use the OPEN LINK command to establish the connections for a PQO conversation. Both the link on the client and the corresponding link on the server must be opened before a client user can access remote server files. The syntax of the OPEN LINK command is the standard Horizon network OPEN LINK syntax. For information about using the OPEN LINK command, see [[Horizon network management.</p>

	===Using the BUMP command===		===Using the BUMP command===
	<p>		<p>

JAL: link repair

2016-02-01T22:10:19Z

link repair

← Older revision		Revision as of 22:10, 1 February 2016
Line 481:		Line 481:
	If an error occurs involving PQO communications, conversation processing is not started or is stopped, and Model 204 automatically displays status codes and sometimes an error message on the client user's terminal or server operator's console. Model 204 also writes the error message to the audit trail of the client or server on which the error occurred.</p>		If an error occurs involving PQO communications, conversation processing is not started or is stopped, and Model 204 automatically displays status codes and sometimes an error message on the client user's terminal or server operator's console. Model 204 also writes the error message to the audit trail of the client or server on which the error occurred.</p>
	<p>		<p>
	PQO errors that involve the underlying communications layer are handled differently from application level errors. For a description of error handling at compilation and evaluation time, see [[PQO: ~~Working with remote~~ files and scattered groups#Errors during compilation and evaluation\|Errors during compilation and evaluation]].</p>		PQO errors that involve the underlying communications layer are handled differently from application level errors. For a description of error handling at compilation and evaluation time, see [[PQO: Remote files and scattered groups#Errors during compilation and evaluation\|Errors during compilation and evaluation]].</p>

	===Communications error display format===		===Communications error display format===

JAL: link repair

2016-01-28T00:43:00Z

link repair

← Older revision		Revision as of 00:43, 28 January 2016
Line 203:		Line 203:
	OPTIONAL (in parentheses) following each optional member. MANDATORY is not displayed if the member is mandatory.		OPTIONAL (in parentheses) following each optional member. MANDATORY is not displayed if the member is mandatory.

	For more information about optional and mandatory group members, see [[PQO: Managing files and groups ~~for PQO~~#Creating ad hoc scattered groups\|Creating ad hoc scattered groups]].		For more information about optional and mandatory group members, see [[PQO: Managing files and groups#Creating ad hoc scattered groups\|Creating ad hoc scattered groups]].
	</li>		</li>
	<li>		<li>

ELowell at 20:23, 14 January 2016

2016-01-14T20:23:21Z

← Older revision		Revision as of 20:23, 14 January 2016
Line 509:		Line 509:
	==See also==		==See also==
	{{Template: PQO topic list}}		{{Template: PQO topic list}}

	~~[[Category: PQO]]~~


	[[Category: PQO]]		[[Category: PQO]]

ELowell: Created page with " ==Overview==
After you have defined the Parallel Query Option/204 network as described in PQO: Defining a PQO network, you need to be aware of certain tasks involved..."

2016-01-14T20:22:56Z

Created page with " ==Overview== After you have defined the Parallel Query Option/204 network as described in PQO: Defining a PQO network, you need to be aware of certain tasks involved..."

New page

==Overview==

After you have defined the Parallel Query Option/204 network as described in [[PQO: Defining a PQO network]], you need to be aware of certain tasks involved in managing the daily operation of the network. These tasks are performed by the network administrator, system administrator, or system manager, and include:
<ul>
<li>Controlling the network </li>
<li>Monitoring network activity</li>
<li>Using the Model 204 audit trail</li>
<li>Interpreting communications errors</li>
</ul>

==Controlling the network==

You use the following types of Model 204 commands to control the PQO network:
<ul>
<li>LU 6.2 network administration commands</li>
<li>BUMP system control command</li>
</ul>

These commands are described in the sections that follow.

===Using the LU 6.2 network administration commands===

The basic set of network administration commands used to control the operation of the PQO network are also used for Horizon. The commands shown in the following table are useful for controlling utilization of resources in the network. 

<table>
<caption>Network administration commands</caption>
<tr class="head">
<th>Command</th>
<th>Description</th>
</tr>
<tr>
<td>[OPEN | CLOSE] LINK</td>
<td>Enables/disables the link specified in a DEFINE LINK command (allocates/releases internal resources).

If a link is closed after a service subsystem has been successfully started, that subsystem remains available to the client (although the link must be reopened before the client can reaccess it).</td>
</tr>
<tr>
<td>[STOP | START] LINK</td>
<td>Halts/resumes operation of the link specified in a DEFINE LINK (deactivates/activates sessions).</td>
</tr>
<tr>
<td>[STOP | START] PROCESSGROUP</td>
<td>
Halts/resumes operation of a processgroup specified in a DEFINE PROCESSGROUP command (enables processgroup redefinition).

If a processgroup is stopped after a service subsystem has been successfully started, that subsystem remains available to the client (although the processgroup must be restarted before the client can reaccess it).</td>
</tr>
<tr>
<td>MODIFY PROCESSGROUP</td>
<td>
Modifies an operational PROCESSGROUP definition (overrides current parameter settings).</td>
</tr>
</table>

The Model 204 network administration commands require User 0, system manager, or system administrator privileges. See the <var class="book">Rocket Model 204 Horizon: Intersystem Processing Guide</var> for information about using the LU 6.2 network administration commands. That volume serves as the primary reference for the commands. 

====Using the OPEN LINK command====

Use the OPEN LINK command to establish the connections for a PQO conversation. Both the link on the client and the corresponding link on the server must be opened before a client user can access remote server files. The syntax of the OPEN LINK command is the standard Horizon network OPEN LINK syntax. For information about using the OPEN LINK command, see the <var class="book">Rocket Model 204 Horizon: Intersystem Processing Guide</var>.
===Using the BUMP command===

Use the <var>[[BUMP command|BUMP]]</var> command to log out a PQO user or to log out all users of a subsystem.

====Bumping a user====

The BUMP command operates differently depending on whether it is issued by a client or a server system manager. 

If the <var class="term">client</var> issues a BUMP command for a user with an open remote file, the client and service threads are freed in the following way: 
<table>
<tr class="head">
<th>Client</th>
</tr>
<tr>
<td>1. Soft restart processing for the user begins.</td>
</tr>
<tr>
<td>2. Files opened by the user are closed.</td>
</tr>
<tr>
<td>3. The user is logged out.</td>
</tr>
<tr>
<td>4. Soft restart processing for the user ends.</td>
</tr>
</table>

<table>
<tr class="head">
<th>Server</th>
</tr>
<tr>
<td>1. The user's service thread is logged out.</td>
</tr>
<tr>
<td>2. Soft restart processing for the user begins.</td>
</tr>
<tr>
<td>3. Local files opened by the user are closed.</td>
</tr>
<tr>
<td>4. The user is logged out.</td>
</tr>
<tr>
<td>5. Soft restart processing for the user ends.</td>
</tr>
</table>

If the <var class="term">server</var> issues a BUMP command for a remote user with a server file open, the service and client threads are freed in the following way: 
<table>
<tr class="head">
<th>Server</th>
</tr>
<tr>
<td>1. Soft restart processing for the user begins.</td>
</tr>
<tr>
<td>2. Local files opened by the user are closed.</td>
</tr>
<tr>
<td>3. The user is logged out.</td>
</tr>
<tr>
<td>4. Lost session message is issued.</td>
</tr>
<tr>
<td>5. Soft restart processing for the user ends.</td>
</tr>
</table>

<table>
<tr class="head">
<th>Client</th>
</tr>
<tr>
<td>1. User query of the remote file receives lost session and communication error messages.</td>
</tr>
<tr>
<td>2. User can open remote file again.</td>
</tr>
</table>

====Bumping all users of a subsystem====

To bump all users of a specified subsystem, use the SUBSYSTEM argument of the BUMP command. The syntax is as follows:

Syntax
BUMP SUBSYSTEM subsysname

Model 204 schedules all users in the subsystem to be bumped, except those in nonbumpable states such as BACKOUT. 

You can also bump all local users of a remote service subsystem. Use the client LOCATION name with BUMP SUBSYSTEM. The syntax is as follows:

Syntax
BUMP SUBSYSTEM subsysname FROM location 

where:

<var class="term">location</var> is the value of the client CCAIN LOCATION parameter (which is also the value of the CLNT field in the LOGWHO command output), or is the symbolic name specified by the process definition.

==Monitoring network activity==

The Model 204 commands used to check on the activity in the PQO network are shown in the following table. 
<table>
<caption>Network monitoring commands</caption>
<tr class="head">
<th>Command</th>
<th>Description</th>
</tr>
<tr>
<td nowrap>DISPLAY GROUP</td>
<td>Displays information about Model 204 groups</td>
</tr>
<tr>
<td>LOGWHO</td>
<td>Identifies the users who are currently logged in to the Model 204 system</td>
</tr>
<tr>
<td>MONITOR</td>
<td>Provides usage statistics for each service thread currently open in the network; also provides information about active local and remote subsystems</td>
</tr>
<tr>
<td>STATUS</td>
<td>Displays information about remotely opened Model 204 files</td>
</tr>
<tr>
<td>VIEW</td>
<td>Specifies the current setting for the named parameter</td>
</tr>
</table>

These commands can be used system-wide. These commands also provide information that identifies users, files, groups, or settings that are particular to the PQO network, as described in the sections that follow. 

===Using the DISPLAY GROUP command===

The DISPLAY GROUP command can display the name and member files of any or all locally created scattered groups. It does not display definitions for groups that were created on other nodes. 

The names of remote files displayed are their file synonyms or remote file specifications (filename AT location). 

In addition, the display might include: 
<ul>
<li>
OPTIONAL (in parentheses) following each optional member. MANDATORY is not displayed if the member is mandatory.

For more information about optional and mandatory group members, see [[PQO: Managing files and groups for PQO#Creating ad hoc scattered groups|Creating ad hoc scattered groups]].
</li>
<li>
MAXFAIL parameter (CREATE GROUP command) value, if it has a value other than asterisk (*). </li>
<li>
UPDTFILE parameter value, including the update file's location if its location was used in the CREATE GROUP definition. </li>
</ul>
===Using the LOGWHO command===

The LOGWHO command lists the users who are currently logged in to Model 204. For PQO, the LOGWHO command operates differently depending on whether it displays information for a client or a server system. 

For each PQO user, LOGWHO shows the remote files currently open. Model 204 includes the following LOGWHO information for a PQO user:
<table>
<tr>
<td>Client</td>
<td>Displays the user ID and the name of the open remote file using the full remote file specification (<var class="term">filename</var> AT <var class="term">location</var>)</td>
</tr>
<tr>
<td>Server</td>
<td>Displays the client user number and user ID, and also displays name of subsystem into which service thread is logged, if any</td>
</tr>
</table>

For example, the LOGWHO command displays the line below for a PQO user on a client system. The user has two files open: a local file, DEMOINV, and a remote file, SALES1, at the BOSTON location:
USER 5 SYSADM L3270621 DEMOINV SALES1 AT BOSTON

The values in this example come from the following sources:
<table>
<tr class="head">
<th>Value</th>
<th>Source</th>
</tr>
<tr>
<td>USER 5</td>
<td>User thread number displayed in Model 204 journal/audit trail user statistics; see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)]]</td>
</tr>
<tr>
<td>SYSADM</td>
<td>User's Model 204 login user ID</td>
</tr>
<tr>
<td>L3270621</td>
<td>User's SNA Communications Server Communications Server (formerly VTAM) terminal ID or z/VM machine name</td>
</tr>
<tr>
<td>DEMOINV</td>
<td>Name of a local file open on the client</td>
</tr>
<tr>
<td>SALES1</td>
<td>File's name as specified in a Model 204 CREATE FILE command on the server</td>
</tr>
<tr>
<td>BOSTON</td>
<td>Node on which the remote file resides; a symbolic destination name specified in a client DEFINE PROCESS command for CCAD2C</td>
</tr>
</table>

In the following example, a LOGWHO command is issued for a PQO service thread. The display includes the following line for a client user. The line includes the service thread's originating client node, the user number of the client thread, and the name of the subsystem into which the client user is logged.
USER 34 MGRXYZ <var class="term">XXXXXXXX</var> SALES1 CLNT: 00005 ON CHICAGO
APSY: DEMOSALES 

The values in this example come from the following sources:
<table>
<tr class="head">
<th>Value</th>
<th>Source</th>
</tr>
<tr>
<td>USER 34</td>
<td>User thread number of service thread as displayed in Model 204 journal/audit trail user statistics</td>
</tr>
<tr>
<td>MGRXYZ</td>
<td>Client user's Model 204 login user ID</td>
</tr>
<tr>
<td><var class="term">XXXXXXXX</var></td>
<td>Value of local DEFINE PROCESSGROUP command REMOTEID parameter</td>
</tr>
<tr>
<td>SALES1</td>
<td>Name of a local file open on the server</td>
</tr>
<tr>
<td>CLNT: 00005</td>
<td>User number at the client thread that is currently using the service thread MGRXYZ (only if user is a client)</td>
</tr>
<tr>
<td>ON CHICAGO</td>
<td>Value of User 0 LOCATION parameter in the client's Model 204 CCAIN</td>
</tr>
<tr>
<td>APSY: DEMOSALES</td>
<td>Name of APSY subsystem into which client thread is logged (only if USER 34 is a service thread)</td>
</tr>
</table>

The <var>[[LOGWHO command|LOGWHO]]</var> command requires system administrator privileges.

===Using the MONITOR command===

The MONITOR command can provide statistics on the current usage of a network entity: link, processgroup, or process. MONITOR can also provide information about active PQO subsystems. This section describes details specific to the PQO output lines.

The MONITOR commands of particular interest for PQO are summarized in the following table. 
<table>
<caption>MONITOR commands</caption>
<tr class="head">
<th>Command</th>
<th>Displays...</th>
</tr>
<tr>
<td>MONITOR LINK</td>
<td>Single summary line, and a detail line for each bound session</td>
</tr>
<tr>
<td>MONITOR PROCESSGROUP</td>
<td>Single summary line, and a detail line for each active conversation</td>
</tr>
<tr>
<td>MONITOR PROCESS</td>
<td>Detail line for each active conversation</td>
</tr>
<tr>
<td>MONITOR SUBSYSTEM</td>
<td>List of active subsystems and information about those subsystems</td>
</tr>
</table>

The MONITOR command for network entities operates the same for PQO as it does for the Horizon network. It requires User 0, system manager, or system administrator privileges. See the <var class="book">Rocket Model 204 Horizon: Intersystem Processing Guide</var> for more information about MONITOR for network entities.

MONITOR SUBSYSTEM output reports whether subsystem members are optional or mandatory, and it has an option (FROM location) that allows PQO users to specify exactly the service subsystem monitored. Ordinary user privileges are required. 

====MONITOR LINK statistics====

Monitoring link activity in the PQO network produces the following difference in the output lines compared to the Horizon statistics: The PROCESS term in the detail line for PQO specifies CCAD2S for the server process or CCAD2C for the client process.

The PROTO term in the summary line specifies LU 6.2 as the type of communications protocol for PQO, the same as is used for Horizon. 

====MONITOR PROCESSGROUP statistics====

Monitoring processgroup activity in the PQO network produces differences in the detail output line compared to the Horizon statistics. The PROCESS term in the detail line for PQO specifies:
<ul>
<li>CCAD2S for an inbound conversation</li>
<li>CCAD2C for an outbound conversation </li>
</ul>

====MONITOR PROCESS statistics====

Monitoring process activity in the PQO network produces differences in the detail output line compared to the Horizon statistics. The CID (conversation ID) term for a PQO conversation ID specifies:
<ul>
<li>CCAD2S (for a server), with the FLGS term set for I (inbound) </li>
<li>Concatenation of the processgroup REMOTEID and LINK values (for a client), with the FLGS term set for O (outbound) </li>
</ul>

====MONITOR SUBSYSTEM command====

To display information about a PQO service subsystem, a server node user specifies the client subsystem name and LOCATION name with the MONITOR SUBSYSTEM command. The format is as follows: 

Syntax
MONITOR SUBSYSTEM (optionlist) subsysname FROM location

where:
<ul>
<li>
<var class="term">optionlist</var> and <var class="term">subsysname</var> are the standard Model 204 MONITOR SUBSYSTEM variable arguments.</li>
<li>
<var class="term">location</var> is the value of the client CCAIN LOCATION parameter, which is also the value of the CLNT field in the LOGWHO command output, or is the symbolic name specified by the process definition.</li>
</ul>
You can also use pattern matching:
MONITOR SUBSYSTEM (optionlist) LIKE 'pattern' FROM 'loc-pattern'

<var class="term">loc-pattern</var> is used to match a client LOCATION parameter. An asterisk (*), meaning all nonlocal locations, is a valid value for <var class="term">loc-pattern</var>. If you use pattern matching, you must specify a pattern for both the subsystem name and location, and you can only match remote location names. 

The MONITOR SUBSYSTEM display includes subsystem member locations (if remote) and whether members are optional or mandatory. A client subsystem display also includes items that are not relevant for the server, such as the storage used for resident requests and whether client subsystem files and groups are automatically or manually opened.

For example, this command produces the output that follows: 
MONITOR SUBSYSTEM (ALL) SALES FROM BOSTON

SUBSYSTEM NAME: SALES FROM BOSTON
SUBSYSTEM STATUS: ACTIVE
NUMBER OF USERS: 1
NUMBER OF PRECOMPILABLE PROCEDURES (SAVED): 1
FILE: BUYERS
STATUS=OPEN,NUSERS=1,DFRD UPDATE=N,MANDATORY
FILE: REG1
STATUS=OPEN,NUSERS=1,DFRD UPDATE=N,OPTIONAL
FILE: REG2
STATUS=CLOSED,NUSERS=1,DFRD UPDATE=N,OPTIONAL
FILE: REG3
STATUS=CLOSED,NUSERS=1,DFRD UPDATE=N,OPTIONAL
FILE: TOTLS


===Using the STATUS command===

For PQO, the STATUS command displays recovery information about remote Model 204 files that were opened during a client Online run.

A STATUS command issued by a client user displays a line with the following format for a remotely opened file:
filename:(REMOTE FILE), LOCATION: name1 ONLINE: name2


where:
<ul>
<li><var class="term">filename</var> is the actual (nonsynonym) name of the remote file. </li>
<li><var class="term">name1</var> is the symbolic name of the file's remote location as specified in the DESTINATION parameter of a local DEFINE PROCESS command. </li>
<li><var class="term">name2</var> is the value of the CCAIN parameter LOCATION in the server Online. </li>
</ul>

For more information about location references, see [[PQO: Defining a PQO network#Client process DESTINATION parameter|Client process DESTINATION parameter]] and [[PQO: Defining a PQO network#Setting the LOCATION parameter|Setting the LOCATION parameter]]. See [[STATUS command: Listing file recovery information]] for details.

===Using the VIEW command===

Use the VIEW command to display the current settings of Model 204 parameters. In PQO remote file contexts, the VIEW command is not reliable for all file parameters. 

In remote file context, reliable VIEW command results are guaranteed only for the following parameters: 
ASTRPPG
ATRPG
CURFILE
CURLOC
FICREATE
FILEORG
FITRANS
HASHKEY
LOCATION
OPENCTL
RECSCTY
SORTKEY

Similarly, for VIEW FPARMS or VIEW TABLES in remote file context, correct information is guaranteed only for the file parameters listed above. 

The following examples are of remote file context VIEW command displays for individual file parameters:
<ul>
<li>VIEW LOCATION displays the value of the CCAIN LOCATION parameter of the Model 204 copy that the file you are in belongs to.

For example, VIEW LOCATION in remote file context displays a line with the following format:

LOCATION name D204 LOCATION

<var class="term">name</var> is the value specified in the LOCATION parameter in the remote Online's User 0 input stream. See [[PQO: Defining a PQO network#Setting the LOCATION parameter|Setting the LOCATION parameter]] for a description of this parameter.
</li>
<li>VIEW CURFILE displays the name of the file you are currently in.

For example, VIEW CURFILE in remote file context displays a line with the following format:

CURFILE name CURRENT FILE

<var class="term">name</var> is the name given to the file when it was created. No file synonyms or remote file specifications are displayed.
</li>
<li>
VIEW CURLOC displays the current file's location.

For example, VIEW CURLOC in remote file context displays a line with the following format:

CURLOC name CURFILE LOCATION IF REMOTE

<var class="term">name</var> is the symbolic name of the file's remote location as specified in the DESTINATION parameter of a local DEFINE PROCESS command.

If the current file is local, VIEW CURLOC displays a line with the following format:

CURLOC name (LOCAL)
</li>
</ul>

==Using the Model 204 audit trail==

Technical Support recommends that PQO clients and servers run with a Model 204 audit trail activated. The audit trail can be printed directly by a Model 204 run without requiring a separate job step. It is invaluable for debugging application programs and for analyzing system performance.

For your own diagnostic purposes or when reporting debugging problems to Technical Support, set the Model 204 <var>[[SYSOPT parameter|SYSOPT]]</var> parameter on server nodes to include audit trail RK lines. The RK lines record calls to Host Language Interface functions, and PQO service threads make use of Model 204 HLI calls to access data.

When you need to conserve audit trail space, turn off the RK lines.

==Interpreting communications errors==

When you use or attempt to use PQO communications, Model 204 generates messages that track the network activity. Model 204 writes these messages to the system's audit trail.

If an error occurs involving PQO communications, conversation processing is not started or is stopped, and Model 204 automatically displays status codes and sometimes an error message on the client user's terminal or server operator's console. Model 204 also writes the error message to the audit trail of the client or server on which the error occurred.

PQO errors that involve the underlying communications layer are handled differently from application level errors. For a description of error handling at compilation and evaluation time, see [[PQO: Working with remote files and scattered groups#Errors during compilation and evaluation|Errors during compilation and evaluation]].

===Communications error display format===

Each PQO error condition involving the underlying communications layer is displayed as one or two error messages. One of these messages contains the status codes. The other line, if any, contains a Model 204 message that helps to describe the condition that caused the error.

An error message that includes the status codes has the following format:
M204.nnnn: COMM[UNICATION] ERROR STATUS=nn, STATUSD=nn

The STATUS value refers to the status of the communications statement last executed. This value is a number value greater than or equal to zero. A value of two or greater indicates that a communications error occurred and identifies the error as belonging to a particular category. 

STATUSD is set to the return code that details the specific error condition within a particular STATUS category. 

STATUS and STATUSD refer to the SOUL $STATUS and $STATUSD function values described in the <var class="book">Rocket Model 204 Horizon: Intersystem Processing Guide</var>.
===Using the status return codes===

The STATUS and STATUSD codes that correspond to PQO communications errors are displayed for informational purposes only and cannot be manipulated by the PQO user in a SOUL procedure.

This limitation on use of the status return codes applies only to communications errors.

===Using the Model 204 error message===

The Rocket Model 204 messages documentation provides a description of Model 204 errors associated with PQO error conditions. Wherever possible, refer to this messages documentation for an explanation of the associated error message.

If an error message is encountered for which no description is available, [[Contacting Rocket Software Technical Support|contact Technical Support]] for assistance.

==See also==
{{Template: PQO topic list}}

[[Category: PQO]]

[[Category: PQO]]

PQO: Managing the PQO network - Revision history

ELowell: /* Using the MONITOR command */

ELowell: /* Communications error display format */

ELowell: /* Using the LU 6.2 network administration commands */

JAL: link repair

JAL: link repair

ELowell at 20:23, 14 January 2016

ELowell: Created page with " ==Overview== After you have defined the Parallel Query Option/204 network as described in PQO: Defining a PQO network, you need to be aware of certain tasks involved..."

ELowell: Created page with " ==Overview==
After you have defined the Parallel Query Option/204 network as described in PQO: Defining a PQO network, you need to be aware of certain tasks involved..."