If more than one System/390® CICS system is communicating with an ASCII system--that
is, with CICS® Transaction Server for Windows or CICS on Open Systems--direct and indirect links are possible.
The links used affect resource definition effort and processing workload.
The processing workload includes data transfer and data conversion.
Where user data conversion is performed by the System/390, it occurs at the
first System/390 system for data inbound from the ASCII system, and at the last System/390 system
for data outbound to the ASCII system. In Figure 1, an ASCII system
running CICS Transaction Server for Windows is linked to two CICS on System/390 systems, directly to CICS1 and
indirectly, through CICS1, to CICS2. CICS1 and CICS2 can be connected in any
way supported for the particular products. Whatever the connection between
CICS1 and CICS2, CICS1 does the conversion for data transferred in either
direction.
Figure 2 shows an ASCII system, CICS Transaction Server for Windows or CICS on Open Systems,
and four CICS System/390 systems. This figure is the basis of the discussion in the
rest of this chapter.
The CICS on System/390 systems comprise:
- One terminal-owning region (TOR)
- Two application-owning regions (AOR1 and AOR2)
- One data-owning region (DOR).
The ASCII system can have a separate LU 6.2 link to each System/390 system. Figure 2 shows three such links: link X to TOR, link Y
to AOR1, and link Z to DOR.
Under Possible approaches, the following assumptions are made about Figure 2.
- A user of the ASCII system can enter a transaction (TRN1) owned by system
AOR1 that requires access to:
- Temporary storage (TS) queues in DOR
- Transient data (TD) queues in systems AOR1, AOR2, and DOR
- File control (FC) files in DOR.
- Function shipping can take place from the ASCII system directly to TOR,
AOR1, and DOR, and indirectly to AOR2.
Note:
Some or all of these requests may require data conversion.
With the setup in Figure 2, and the stated assumptions, various
scenarios are possible, as discussed below.
Note:
In the discussion, the term "data conversion modules"
refers to:
- The standard data conversion program
- The data conversion table
- The user-replaceable data conversion program.
All three of these items are required for function shipping and DPL,
but only the first two for transaction routing.
Transaction routing: ASCII--TOR--AOR1
The following definitions are necessary:
- In the ASCII system, a remote definition of the transaction (the remote
system is specified as TOR).
- In TOR:
- A remote terminal definition (or a shipped terminal definition)
- A remote definition of the transaction (the remote system is specified
as AOR1).
- In AOR1:
- A remote terminal definition (or a shipped terminal definition).
- Remote definitions of the files owned by DOR that are to be accessed by
the transaction.
- Remote definitions of the temporary storage queues in DOR.
- Remote definitions of the transient data destinations in DOR.
- Local transient data definitions.
- Local transaction and program definitions.
- If AOR1 is a CICS/VSE Version 2 system, an indirect connection
to the ASCII system, via TOR. Indirect connections are required only for transaction
routing across intermediate systems. For information about defining indirect
connections, see the Intercommunication Guide for your CICS System/390 product.
- In DOR:
- Local transient data definitions
- Local temporary storage definitions
- Local file definitions.
The ASCII system uses its system services to perform the data conversion
from ASCII to EBCDIC.
Transaction routing: ASCII--AOR1
The same resource definitions are required as for transaction routing through
TOR (see above), except that:
- In the ASCII system, on the remote transaction definition, the remote
system is specified as AOR1
- In TOR, the remote terminal and transaction definitions are no longer
necessary
- In AOR1, the indirect connection to the ASCII system is no longer necessary.
Function shipping: ASCII--TOR--AOR1--DOR
The following definitions are necessary:
- In the ASCII system, remote definitions of the resources to be accessed
- In TOR:
- Remote definitions of the resources to be accessed
- Definitions of the data conversion modules.
- In AOR1:
- Local definitions of its own resources
- Remote definitions of resources owned by DOR, that are to be accessed
by the ASCII system.
- In DOR, local definitions of its own resources.
The data conversion modules need to be defined in only one system, TOR,
which does the ASCII<->EBCDIC conversion on the transmitted
user data.
Function shipping: ASCII--AOR1--DOR
The same resource definitions are required as for the previous example,
except that:
- The definitions in TOR are not required
- The data conversion module definitions are in AOR1, which does the ASCII<->EBCDIC
conversion on the transmitted user data.
Function shipping: ASCII--AOR1 and ASCII--DOR
The same resource definitions are required as for the previous example,
except that:
- The remote resource definitions are not required in AOR1
- AOR1 and DOR each do ASCII<->EBCDIC conversion on
transmitted user data, depending on which system is the target of each function-shipped
request. You must therefore define the data conversion modules in both AOR1
and DOR.
A direct link from the workstation to the target CICS system gives the shortest path length.
If you have several target CICS on System/390 systems, you can ship all requests through
a single system in which you have defined the data conversion modules. This
enables you to define the data conversion modules in only one place, at the
expense of a longer path length and the need to create more remote resource
definitions.
[[ Contents Previous Page | Next Page Index ]]