Pathway/iTS Web Client Programming Manual (H06.03+, J06.03+)

Table Of Contents
Introduction to Pathway/iTS 1.1
HP NonStop Pathway/iTS Web Client Programming Manual520270-003
7-4
Web Clients in Pathway/iTS 1.1
its reply. It ends the dialog by returning the file-system error 0 (FEOK). The server
replies with the file-system error 70 (FECONTINUE) to continue with the dialog. The
requester calls DIALOG-ABORT to abort the dialog. The requester calls DIALOG-END
to clean up resources after the server has ended or aborted the dialog. Only one active
dialog per requester terminal is allowed at any given time. Under such condition, a
maximum of 256 active dialogs per TCP (from all terminals managed under it) are
allowed. A dialog-based communication also requires that the requester and server
must be designed to work together. For details on how to write context sensitive
Pathway servers, see the
TS/MP Pathsend and Server Programming Manual
.
Web Clients in Pathway/iTS 1.1
The web client feature of Pathway/iTS 1.1 enables users to convert the DIALOG verbs
in addition to the old SCOBOL features to a Web client and then, build and deploy the
resulting client in a Pathway environment. Also, Pathway/iTS 1.1, the Session-length
parameter is ignored as long as the dialog is outstanding. After a successful DIALOG-
BEGIN operation, the session will be active like the BT-ET block until the DIALOG-
END or DIALOG-ABORT operation is complete, regardless of the specified number of
I/O operations. After the DIALOG-END or DIALOG-ABORT operation, the session will
be closed if required.
Difference Between Pathway/iTS 1.0 and
Pathway/iTS 1.1
PATHTCP4, a Pathsend requester, uses the Pathsend APIs to process the
SEND/DIALOG-BEGIN/DIALOG-SEND/DIALOG-END/DIALOG-ABORT statements.
There are certain differences between Pathway/iTS 1.0 and Pathway/iTS 1.1.
Server Process Opener and Timeouts on Send to Servers
PATHTCP3 and PATHTCP4 differ in opening the server processes while processing a
SEND or DIALOG-BEGIN verb. PATHTCP4 being a Pathsend requester does not open
the server process. Instead, it uses a Pathsend call. This causes the TS/MP ROUT
($ZLnn) process running on the CPU of primary TCP to open the server process.
Pathway/iTS 1.0 users who plan to migrate to PATHTCP4 are required to check if their
server programs do any validation in terms of who opens the server process. Under
such condition, with PATHTCP4, the servers will receive the cancel message (incase
there is a server timeout when the SEND or DIALOG-BEGIN or DIALOG-SEND to
server is outstanding) from the TS/MP ROUT process rather than the TCP process.
TCP Checkpoint Strategy
PATHTCP4 adopts these checkpoint strategies:
If a SEND verb is being performed under transaction (BEGIN-TRANSACTION is
performed before executing the SEND statement), PATHTCP4 does not perform
checkpoint before and after the SEND statement. If the primary TCP fails while