TS/MP Pathsend and Server Programming Manual (H06.05+, J06.03+)

IDS Requesters
Standard SCREEN COBOL requesters are screen oriented; they send data back and forth between
the Working-Storage Section of the program and a terminal’s display screen by way of screen
templates defined in the Screen Section. Standard SCREEN COBOL requesters use SCREEN COBOL
ACCEPT and DISPLAY statements in the Procedure Division to interact with display terminals.
SCREEN COBOL requesters that employ the IDS facility within the TCP send data back and forth
between the Working-Storage Section and an intelligent device (or a front-end process that controls
the device) by way of message templates defined in the Message Section. IDS requesters use
SCREEN COBOL SEND MESSAGE statements and their associated REPLY clauses in the Procedure
Division to interact with the intelligent devices or front-end processes.
Although IDS sends and receives data through Message Section templates instead of Screen Section
templates, the TCP still provides:
• Link management for access to Pathway server classes
• TMF support to ensure transaction protection and database integrity
• Fault tolerance through process pairs
• Multithreading and multitasking
• Expanded I/O editing support for data streams from intelligent devices
For information about designing and coding IDS requesters, refer to the Pathway/iTS TCP and
Terminal Programming Guide.
Pathsend Requesters
As an alternative to writing SCREEN COBOL requesters, you can write Pathsend requesters in C,
C++, COBOL85, Pascal, TAL, or pTAL. In such requesters, you use Pathsend procedure calls to
communicate with Pathway servers. The LINKMON process or the ACS subsystem processes
manage links to your server processes on behalf of Pathsend requesters.
Design Considerations
Pathsend requesters are a good choice for your applications if you need to:
• Take a high volume of transactions from a limited number of devices. In this scenario, there
are relatively few requester processes, the requesters are busy, and configuration and
management is minimal.
• Access servers that are shared by Pathway requesters and applications other than OLTP
applications: for example, a security checking server or a logging server. If such servers are
used infrequently or if the workload varies, server processes can be automatically deleted
when not needed and restarted through the PATHMON process when needed again.
• Access servers from environments containing a mix of online transaction processing and batch
processing: that is, environments where the same set of servers handle both online requests
and requests from batch applications such as NetBatch Plus processes.
• Write nested servers, which act as requesters by making requests to servers in other server
classes, perhaps server classes managed by a different PATHMON process.
• Write context-sensitive servers, which are discussed later in this section under “Designing
Server Programs.”
Pathsend procedure calls give you more flexibility than WRITEREAD calls for serverto- server
communication. The application gets all the advantages of server classes, including advantages
not readily available with WRITEREAD; for example, load balancing, adjusting the number of
servers to fit response-time requirements, and configuration and operations management. You can
use the Pathsend procedure calls in C, C++, COBOL85, Pascal, TAL, and pTAL programs.
Designing Requester Programs 37