Browse Prior Art Database

Accessing CICS/ESA Applications from a Non-CICS Environment

IP.com Disclosure Number: IPCOM000111454D
Original Publication Date: 1994-Feb-01
Included in the Prior Art Database: 2005-Mar-26
Document File: 2 page(s) / 116K

Publishing Venue

IBM

Related People

Malaika, S: AUTHOR [+4]

Abstract

Disclosed is the ability to link to CICS/ESA programs from an MVS non-CICS/ESA environment. Previously CICS/ESA programs could only be linked to/from other CICS environments for calling and receiving a reply.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 45% of the total text.

Accessing CICS/ESA Applications from a Non-CICS Environment

      Disclosed is the ability to link to CICS/ESA programs from an
MVS non-CICS/ESA environment.  Previously CICS/ESA programs could
only be linked to/from other CICS environments for calling and
receiving a reply.

      CICS/ESA programs can LINK to other CICS programs by using the
EXEC CICS LINK request, and since CICS/ESA Version 3.3, can specify
an applied on the LINK command in order to link to a program running
on another CICS system; this is called Distributed Program Link, or
DPL.   What has not been possible is to be able to link to a CICS/ESA
program from an environment other than a CICS system, e.g., from TSO,
or from a pure MVS batch program.  This kind of function could be
required for many different purposes, such as the ability to take
CICS resources off-line at the start of an MVS batch job (and
bringing them on-line again at the end of these jobs), accessing and
updating resources while they are being accessed by CICS without loss
of integrity, opening and closing files, enabling and disabling
transactions, so eliminating the need for master terminal operation
during system backup and recovery procedures and finally to make CICS
application programs more easily accessible from non-CICS
environments.

      To solve this problem, an API is provided that can be used from
within batch programs.  In fact, 2 different APIs have been provided:
one low level (called the Call level API), aimed at system
programmers, vendors, etc. and one at a higher level (called the EXEC
API), aimed at application programmers.   What follows is a brief
explanation of the two types of API.   Throughout the explanation,
the term "The Batch Facility" is used to refer to the code written to
fulfil these requests, and provide the bridge between the batch
applications and the CICS program.

      Call Level API is a low level API, and consists of a suite of
six calls, which allow the batch program to allocate and open a
connection (known as a pipe) to a particular CICS system, and to pass
Distributed Program Link (DPL) requests along it.   The six calls
provided are:

1.  An Initialize User call, which registers the caller (by name) as
    a user to the Batch Facility.   The Batch Facility returns to the
    caller a token to identify itself on all further calls.   This
    allows the calling application to co-exist alongside the other
    users of the Batch Facility, and to allow the Batch Facility to
    distinguish between its (possibly many) callers.

2.  An Allocate Pipe call, which allocates a single pipe,
    representing a connection between the batch caller and the target
    CICS system.  It is on this request that the caller identifies
    the CICS system with which it wishes to communicate.   The
    application can issue as many Allocate Pipe requests as it likes,
    to any number of different CICS systems.   The B...