1. Introduction to CICS Transaction Server
9/7/2004
Introduction to CICS Transaction Server
for OS/390 – Unit 4
Page

2. Unit 4: CICS intercommunication
9/7/2004
Unit 4: CICS intercommunication
Topics:
4A. Intercommunication facilities
4B. Interregion and intersystem communication
4C. CICS and the Internet
Page

3. 9/7/2004
Unit 4 overview
Many organizations have resources such as terminals, application
programs, and data spread out over one or more systems or CICSPlex
setups.
CICS TS for OS/390 supplies several facilities to allow you to access
CICS resources across a CICSPlex, over an intranet, or over the
Internet. This unit describes these facilities and the advantages that they
offer. It also introduces several products that provide a range of options
in configuring a CICS setup for Web browser access.
Page

4. 9/7/2004
Unit 4 objectives
This is what you should be able to do upon completing this unit:
Describe the intercommunication facilities that allow the sharing of CICS resources across regions and systems
List the advantages of distributing transactions and programs across regions and systems
Identify the applications of multiregion operation in CICS TS for OS/390
Describe the possible system configurations for setting up intersystem communication
List and describe the facilities available in CICS TS for OS/390 for making CICS available over the Internet or an intranet
Page

5. 4A. Intercommunication facilities
9/7/2004
4A. Intercommunication facilities
In previous units, you learned that every CICS setup controls its own
resources, such as files, terminals and local application programs.
However, through CICS intercommunication facilities, a CICS system
can establish links to other systems and gain access to remote
resources. Such intercommunication permits the sharing of resources
and transferring of data across several systems.
CICS employs these methods for communicating between systems:
Function shipping
Asynchronous processing
Transaction routing
Distributed program link (DPL)
Distributed transaction programming
Page

6. 9/7/2004
4A. Function shipping
Function shipping allows multiple systems to share resources such as
files, temporary storage or application programs. When function
shipping is used, a program is invoked in a local CICS system and
accesses resources owned by a remote system. The program operates
as though the resources are resident on the local system.
Access gained through function shipping allows both reading from and
writing to the resource, as well as restarting and recovery operations.
Page

7. 4A. Function shipping In developing applications,
9/7/2004
4A. Function shipping
In developing applications,
CICS systems programmers
can specify that a required
resource is not located on the
local or requesting system,
but on a remote or owning
system.
Application programs can use EXEC CICS commands to perform these function shipping operations:
Shipping file control requests to another CICS system
Shipping transient data and temporary storage requests to another CICS system for data transfer
Initiating transactions in another CICS or IMS system by shipping START commands (called asynchronous processing)
Page

8. 4A. Function shipping When a file-control command is
9/7/2004
4A. Function shipping
When a file-control command is
issued for a resource, first the
EXEC interface program
determines where the resource
is located.
Page

9. 4A. Function shipping If the resource is on another system,
9/7/2004
4A. Function shipping
If the resource is on another system,
the request is passed to the owning
system.
The owning system runs the request
in a mirror transaction, a local re-
creation of the original request.
Application programs can use EXEC
CICS commands to perform
These function shipping operations:
Shipping file control requests to another CICS system
Shipping transient data and temporary storage requests to another CICS system for data transfer
Initiating transactions in another CICS or IMS system by shipping START commands (called asynchronous processing)
When the originating system requests resources in more than one remote CICS system, multiple mirror transactions can be invoked.
If the originating system requests resources that are also remote to the accessed system, chained mirror transactions can be invoked.
Page

10. 4A. Function shipping Once the request is completed,
9/7/2004
4A. Function shipping
Once the request is completed,
a reply is sent back to the
originating CICS system.
Page

11. 9/7/2004
4A. Function shipping
Some transactions that involve function shipping:
EXEC CICS READ FILE (‘RFILE’) – A simple read request is passed from one CICS system to another and returned.
EXEC CICS READ UPDATE FILE – A request to read file updates is passed from one CICS system to another and returned.
EXEC CICS REWRITE FILE – A request to rewrite a remote file is passed from one CICS system to another.
Page

12. 9/7/2004
4A. Function shipping
Asynchronous processing is a type of function shipping where a
transaction is initiated in a remote CICS system by shipping an EXEC
CICS START request to a remote system.
The processing is asynchronous because the performance of the
request on the remote system proceeds independently of any
implementation on the initiating system. To return a reply when the
transaction is completed, the remote system can initiate a transaction in
the local system.
Normally, a START command would schedule a transaction on the local system. In asynchronous processing, CICS recognizes that the requested resource is on a remote system, either through transaction resource definition or through a specification in the SYSID option of the START command.
Page

13. 9/7/2004
4A. Transaction routing
Another type of intercommunication in CICS is transaction routing,
which allows terminals connected to one CICS system to run
transactions within a remote CICS system. This means that you can
distribute terminals and transactions throughout a network of systems
and still have the ability to run any transaction from any terminal.
Page

14. 4A. Distributed program link
9/7/2004
4A. Distributed program link
Distributed program link (DPL)
enables a CICS program to call a
program on a remote system or
CICS region.
The DPL exploits the LINK
command by allowing the linking
and linked-to application to reside
in different systems or regions.
This potentially reduces the
number of data transfers between
systems, thus improving
performance.
Recall from Unit 1 that the LINK command is used to link two programs together. With the LINK command, the linked-to program executes independently, and then returns control to the linking program.
Page

15. 4A. Distributed program link
9/7/2004
4A. Distributed program link
A few key advantages to using DPL with CICS:
Programs execute closer to accessed resources, which results in enhanced performance and reduces the number of function shipping requests.
DPL is a simpler alternative to Distributed Transaction Processing (see the next topic).
Page

16. 4A. Distributed transaction processing
9/7/2004
4A. Distributed transaction processing
Distribution transaction
processing (DTP) is the
distribution of transaction
functions over several programs
within a network of systems.
Application programs involving
DTP are complex to develop
because they are able to
initiate and control their own
intercommunication between
transactions.
Page

17. 4A. Distributed transaction processing
9/7/2004
4A. Distributed transaction processing
DTP differs from the other
intercommunication facilities
discussed thus far in that it
employs synchronous processing.
The communication is dynamic,
and not predefined by transaction
definitions. However, transactions
in DTP are designed to
communicate with other
transactions as efficiently as
possible.
Unlike asynchronous processing, in which processes must interrupt each other in order to communicate, synchronous processing allows communication between different transactions or components of transactions that are running concurrently on separate systems.
Page

18. 4A. Distributed transaction processing
9/7/2004
4A. Distributed transaction processing
In large or high-traffic Parallel Sysplex setups, complex CICS
innovations such as DTP serve to reduce the potential problems
associated with simpler, more transparent and slower transaction
facilities.
DTP serves to streamline and synchronize transactions, and allows
complex programming conversations between CICS systems. This
helps to prevent heavy system use from resulting in sluggish
performance or system errors.
In the banking transaction example in Unit 3, DTP would be at work behind the scenes, reducing the response time and ensuring greater accuracy in fulfilling the customer’s ATM transaction request.
Page

19. 4A. Distributed transaction processing
9/7/2004
4A. Distributed transaction processing
DTP is not suited to all systems.
For smaller and less heavily used
systems, DTP might not be
necessary. The complexity of DTP
might demand too much technical
expertise to set up and maintain it
in some user environments.
Page

20. 4B. Multiregion operation
9/7/2004
4B. Multiregion operation
CICS multiregion operation (MRO)
enables CICS systems that are
running in the same OS/390 system
or within a Parallel Sysplex setup to
communicate with each other.
MRO does not enable communication
between a CICS setup and a non-
CICS system, such as an IMS or DB2
system.
MRO provides all five of the
intercommunication facilities listed at
the right.
Page

21. 4B. Multiregion operation
9/7/2004
4B. Multiregion operation
These are some of the uses of
multiregion operation (MRO):
Program development
Providing reliable database access
Setting up department-specific regions
Multiprocessing
Page

22. 4B. Multiregion operation
9/7/2004
4B. Multiregion operation
MRO allows for easy and risk-free
testing of newly written applications
by making it possible to set up a
separate CICS system that is
designated specifically for testing.
Test transactions can access resources in the production-designated system through function shipping.
Transaction routing allows terminals that are connected to the production system to be used for running test transactions.
Page

23. 4B. Multiregion operation
9/7/2004
4B. Multiregion operation
MRO allows you to set up your system to
reduce the possibility that unreliable
applications will disable the system or
other applications. You can also use it
to increase the reliability of database
access.
You could divide your system into multiple
regions, dedicating one region to less
reliable applications, and thus separating
them from more reliable applications. The
applications in one region can still access
resources in other regions through
interregion communications (IRC).
To increase the reliability of database
access, you can designate a database-
owning region that contains no user
applications, and thus might not be subject
to the effects of an unstable application.
You could divide your system into multiple regions, dedicating one region to less reliable applications, and thus separating them from more reliable applications. The applications in one region can still access resources in other regions through interregion communication (IRC).
To increase the reliability of database access, you can designate a database-owning region that contains no user applications, and thus may not be subject to the effects of an unstable application.
Page

24. 4B. Multiregion operation
9/7/2004
4B. Multiregion operation
MRO allows you to set up a
CICSPlex where each department
of an organization has its own
CICS system. IRC allows one
department to access another
department’s resources and data.
With transaction routing, any
terminal can run a transaction on
any system. Thus, terminals do
not need to be designated as
belonging to a specific department.
MRO within a CICSPlex allows you to benefit from multiprocessing. The CICSPlex can be set up to allow access to the transactions and data resources in any of the systems.
Transaction routing helps to simplify the system interface by presenting a single system image to the user.
Page

25. 4B. Intersystem communication
9/7/2004
4B. Intersystem communication
Intersystem communication (ISC)
is the communication between a
CICS system and another system
or set of systems that are
networked together.
Communication between systems
in ISC uses the telecommunication
protocols of Systems Network
Architecture (SNA).
Page

26. 4B. Intersystem communication
9/7/2004
4B. Intersystem communication
There are three basic ways in which subsystems can be connected for
intersystem communication:
ISC within a single operating system
ISC between physically adjacent operating systems
ISC between physically remote operating systems
Communication can take place between CICS and non-CICS systems.
For example, intersystem communication can take place between a
CICS Transaction Server for OS/390 system and an IMS system.
Intersystem communication can make use of the same facilities as
MRO, including function shipping, transaction routing, DLP and DTP.
Intersystem communication can make use of the same facilities as MRO, including function shipping, transaction routing, DLP, and DTP.
Page

27. 4C. CICS from a browser CICS TS for OS/390 provides you
9/7/2004
4C. CICS from a browser
CICS TS for OS/390 provides you
with the facilities for making
transaction-processing services
available over the Internet or an
intranet.
There are several different means
by which a client application
program or an Internet browser
can communicate with CICS and
request CICS services.
Page

28. 4C. CICS from a browser Web browsers can communicate
9/7/2004
4C. CICS from a browser
Web browsers can communicate
directly with CICS application
programs without an intermediate
gateway or Web server through
CICS Web support (CWS).
A user selects the URL for the CWS from a browser window. The request is sent to CICS using hypertext transfer protocol (HTTP). CICS TS, which supports HTTP, receives the request and directs it to the CWS, where an alias transaction is started.
Page

29. 4C. CICS from a browser Instead of accessing CICS directly
9/7/2004
4C. CICS from a browser
Instead of accessing CICS directly
through CWS, you can also
access CICS services through a
server on the OS/390 platform.
For example, you can obtain a
secure connection with CICS
through an IBM WebSphere
Application Server for OS/390.
Page

30. 4C. CICS from a browser You can also access CICS TS for
9/7/2004
4C. CICS from a browser
You can also access CICS TS for
OS/390 via a non-OS/390 Web
server that is connected via a
network.
Communicating with CICS in this
way uses the External CICS
Interface (EXCI). EXCI is a form of
function shipping, where the
incoming request is processed by
a mirror transaction in the linked-
to system.
Page

31. 4C. CICS from a browser Another way to access CICS from
9/7/2004
4C. CICS from a browser
Another way to access CICS from
a Web browser is through the CICS
Transaction Gateway.
The CICS Transaction Gateway
uses the CICS External Call
Interface (EXCI) to pass requests
to CICS.
A gateway is an intermediary connection server that accepts requests from Internet browsers, access the information from CICS TS for OS/390, and returns the requested information via the Web.
Page

32. 4C. CICS Transaction Gateway
9/7/2004
4C. CICS Transaction Gateway
IBM’s CICS Transaction Gateway for OS/390 provides a set of Java-
based Web server facilities allowing access to CICS applications from a
Web browser.
These facilities include:
A JavaGateway application that interfaces with CICS applications running on CICS servers. This communication takes place through the CICS External Call Interface (EXCI).
A CICS Java class library that provides an application programming interface (API), and facilitates communication between the gateway application and a Java application or applet.
Page

33. 4C. CICS Transaction Gateway
9/7/2004
4C. CICS Transaction Gateway
The Java classes and JavaBeans
supplied by CICS Transaction
Gateway allow you to write Java
Web server code to handle
browser requests for CICS
services.
You can also use these facilities
to code applets.
Applets are small Java programs downloaded from the Web and executed by Web browsers or network computers.
Page

34. 4C. CICS Transaction Gateway
9/7/2004
4C. CICS Transaction Gateway
One of the Java classes included
in the CICS Java class library is
the JavaGateway class, which is
used to establish communication
with the gateway process.
Another class, the ECIRequest
class, is used to specify external
call interface (ECI) calls.
ECI is the interface that allows non-CICS applications to call a CICS program in a CICS server.
Page

35. 4C. CICS Transaction Gateway
9/7/2004
4C. CICS Transaction Gateway
The steps involved in accessing CICS using the CICS Transaction Gateway from a Web browser:
1. Browser calls a Web server using HTTP to get HTML pages.
2. Browser finds an applet tag for the applet that will communicate with CICS, and calls Web server to get the applet and classes that it requires.
3. After the browser receives an applet, it runs the applet.
The steps involved in accessing CICS using the CICS Transaction Gateway from a Web browser:
Browser calls Web server using HTTP to get HTML pages.
Browser finds an applet tag for the applet that will communicate with CICS, and calls Web server to get the applet and classes that it requires.
After the browser receives the applet, it executes the applet.
Page

36. 4C. CICS Transaction Gateway
9/7/2004
4C. CICS Transaction Gateway
4.The implemented applet creates a JavaGateway object, which calls the CICS Transaction Gateway for OS/390.
The applet also creates an ECIRequest object to represent its request for a CICS program.
Page

37. 4C. CICS Transaction Gateway
9/7/2004
4C. CICS Transaction Gateway
5.The ECIRequest object is passed to the gateway, which then calls the CICS program.
6.When the program is finished, the results are returned to the browser by way of the gateway.
Page

38. 9/7/2004
4C. CICS Web Interface
The CICS Web support (CWS) is a set of CICS services that support direct access to CICS from a Web browser over a TCP/IP connection.
CWS allows customers to use the transaction processing facilities of CICS for transactions conducted over the Internet without an intermediate gateway to separate Web server.
The CICS Web support (CWS) is a set of CICS services that support direct access to CICS from a Web browser over a TCP/IP connection.
CWS allows customers to use the transaction processing facilities of CICS for transactions conducted over the Internet without an intermediate gateway or separate Web server.
Page

39. 9/7/2004
4C. CICS Web Interface
With CICS you can build CICS HTML application utilities and provide Internet or intranet access to CICS without a Web server.
However, the facilities provided by CWS do not replace those performed by a Web server. You should use a separate server if you need facilities that provide GIFs, applets, or other items that might be referenced from the CICS pages.
With CICS you can build CICS HTML application utilities and provide Internet or intranet access to CICS without a Web server.
However, the facilities provided by CWS do not replace those performed by a Web server. You should use a separate server if you need facilities that provide GIFs, applets, or other items that may be referenced from the CICS pages.
Page

40. 4C. CICS Web interface CWS accepts two types of requests:
9/7/2004
4C. CICS Web interface
CWS accepts two types of requests:
Requests from Web browsers connected via a TCP/IP port that is designated for CWS
Requests from Web browsers connected to IBM WebSphere Application Server for OS/390.
With CICS you can build application
utilities and provide Internet or intranet
access to CICS without a Web server.
However, the facilities provided by CWS
do not replace those performed by a
Web server. You should use a separate
server if you need facilities that provide
GIFs, applets, or other items that may be
referenced from the CICS pages.
For requests from Web browsers connected via a TCP/IP port that is designated for CWS, a user-replaceable application translates the HTTP request into a request for CICS transaction processing services.
For requests from Web browsers connected to IBM WebSphere Application Server for OS/390, a CICS-supplied WebServer plugin operating within the server relates the HTTP request to the transaction processing services.
Page

41. 9/7/2004
4C. CICS Web interface
For requests from Web browsers connected via a TCP/IP port that is designated fro CWS, a user-replaceable application translates the HTTP request into a request for CICS transaction processing services.
For requests from Web browsers connected to IBM WebSphere Application Server for OS/390, A CICS-supplied WebServer plug-in operating within the server relates the HTTP request to the transaction processing services.
Page

42. Unit 4 summary This is what you learned in this unit:
9/7/2004
Unit 4 summary
This is what you learned in this unit:
MRO allows communication between different CICS regions within a single system or CICSPlex.
ISC connects separate systems, including non-CICS systems, for intercommunication.
CICS TS for OS/390 provides five facilities for intercommunication: function shipping, asynchronous processing, transaction routing, DPL and DTP.
(continued)
Page

43. 9/7/2004
Unit 4 summary
Intercommunication permits the sharing of resources across systems and regions.
All five types of intercommunication are available in both MRO and ISC setups.
There are several possibilities for making CICS transaction processing services available over the Internet or an intranet: CICS Web Support provides access to CICS with or without an intermediate Web server or gateway; CICS Transaction Gateway serves as an intermediary between CICS and a Web browser.
Page