IBM Tivoli NetView for z/OS Programming: Pipes - IBM notice

Using Tivoli NetView for z/OS SQL Stages for Access to DB2
use PIPE SQL COMMIT WORK | CONS at the start of SQL processing to ensure
that any previous plan is closed. Alternatively, a PIPE SQL NOCLOSE CONNECT
RESET | CONS can be used to ensure that the local database is being used
and the plan is open.
The following are reasons to use NOCLOSE:
v When using SQL CONNECT to connect a remote database, a NOCLOSE enables
you to keep the remote connection between two pipes. You might find it
convenient to open a remote connection in one pipe, do some processing in
REXX, and finish working with the remote connection in a second pipe. Specify
NOCLOSE in the first pipe and omit the operand everywhere in the second
pipe.
v When using database locks in SQL, use NOCLOSE to keep the locks from one
PIPE to the next.
v Other applications requiring two pipes to implement one function, typically,
with other (REXX) processing between the two pipes.
Using Secondary Output Streams with SQL
SQL EXECUTE processes multiple I/O requests from the primary input stream that
has multiple insert, or query statements, or a mixture of these.
The results of the queries are written to the primary output stream, and have the
color attribute green (CG). Output data is written using Tivoli NetView for z/OS
message type double quotation mark (HDRTYPEK).
If the secondary output stream is defined and connected, any error messages are
written to it. If a secondary stream is not defined, error output is not sent to the
primary stream, but escapes to the parent pipe or is displayed. Error messages also
have the color attribute red (CR). Error messages are written with the Tivoli
NetView for z/OS message type apostrophe (HDRTYPEJ).
Diagnostic messages (from the SQL TEST or DIAGNOSE options) are color-coded
yellow (CY) and are written to the secondary stream. Diagnostic messages are
written with the Tivoli NetView for z/OS message type apostrophe (HDRTYPEJ).
Using Concurrent SQL Stages
You can process the results of a query to construct DB2 statements and queries
processed in a subsequent SQL stage. As seen from DB2, all concurrent SQL stages
are considered to be the same program using a single cursor.
The option NOCOMMIT must be specified when multiple SQL stages are running
concurrently. Each stage uses its own work areas. Up to 10 SQL stages can be
coded in one PIPE.
If one stage fails with a DB2 error, the unit of work is rolled back. All subsequent
SQL stages in the pipeline ignore all input. Messages indicating the failure are
issued. NOCLOSE is respected if coded within the pipeline.
You can process a query and store the result in a REXX stemmed array, test the
return code, and issue the second SQL pipeline only when the first one has
completed satisfactorily.
When accessing DB2 subsystems from a Tivoli NetView for z/OS system, you
cannot directly access multiple DB2 subsystems on a single task without having
Chapter 6. Using Tivoli NetView for z/OS SQL Stages for Access to DB2 339