|
Application
Transformation with
CICS Transaction
Server for z/OS V3.1
It isn't just about XML Web services
Read
about CICS TS V3.1 Web Services
by
Anura Guruge,
Editor at Large and
author of
"Web Services: Theory
and Practice"
[at
Amazon.com etc.]
The latest release
of mainframe CICS [i.e. T.S. V3.1], unveiled on
November 30, 2004,
was rightly lauded for its ground-breaking, SOA empowering,
bi-directional XML Web services capabilities.
Theses Web services features, categorized by IBM as offering
“increased integration of CICS applications”, though strategic,
were, however, not the only major ‘host integration’ functionality
of particular note within this release. IBM grouped the
enhancements in T.S. V3.1 into three primary areas:
1.
Increased
integration of CICS applications
2.
Enhanced
application transformation
3.
Improved
performance and enterprise management
source: IBM
I
IBM's
depiction of the SOA-centric CICS TS V3.1 for z/OS with its 3 groups
of enhancements
The first group of
enhancements, in the so called ‘integration’ category, is, as
to be expected, spearheaded by the CICS Web services support but it
also includes improvements made in the areas of HTTP
interoperability and SSL/TLS security. With this latest HTTP
support, compliant with the HTTP version 1.1 specification, CICS can
now act as both an HTTP server as well as HTTP client – using simple
EXEC CICS commands. On the security front, the previously
existing support for SSL 3.0 has now been extended to embrace TLS
1.0, the successor standard to SSL – replete with accommodation for
the 128- and 256-bit Advanced Encryption Standard (AES)
cipher suites (where it is worth noting that most commercial-sector
Web products, including Internet Explorer 6.0, currently use 128-bit
ciphers for most of their standard encryption needs).
Enhanced
application transformation
This, the second
category of enhancements, were described by
IBM as
functionality to facilitate the enhancements of existing
applications as well as the development of new applications using
contemporary languages, constructs, and tools. This V3.1
application transformation category includes four distinct features:
1.
optimized
data exchange between CICS programs via a new
API
2.
better
integration of programs written in assembler [i.e.
BAL] with the CICS Language Environment technology
3.
64-bit address “tolerance” where 64-bit applications can now run as
task-related user exists (TRUEs) within the CICS address space –
though CICS T.S. V3.1 per se does not support the native execution
of 64-bit applications
4.
Unicode code-page conversion now added to CICS previous capability
to convert between EBCDIC and ASCII
to provide bi-directional conversion between EBCDIC or ASCII and
Unicode UTF-8 or UTF-16.
Of
these, the most significant, without doubt, is the new inter-program
data transfer
API. This API,
based around the concepts of containers and channels, provides a
21st century alternative to the much beloved, but long-in-the–tooth
CICS COMMAREA approach – with its 32KB data size restriction which
is proving to be a tad too constraining with the current penchant
for using verbose XML. The COMMAREA interface was the way that most
applications traditionally exchanged data parameter data using the
EXEC CICS LINK API. This API specified (or pointed to) a
communications area (COMMAREA) – where the COMMAREA was a
pre-allocated memory ‘buffer’ that contained the data to be
transferred. The data in the COMMAREA would be ‘typed’ data
representing a specific data structure defined by the applications.
The new
API though retaining the comfortably
familiar EXEC CICS ‘API’ convention and supporting structured data
is meant to be more flexible and capable of dealing, with no
caveats, with large volumes of data, in both XML and non-XML form.
It is also supposedly more intuitive, though I suspect the jury is
still out on that one. The new API relies on two new data
transferring ‘mechanisms’ referred to as containers and channels –
where a channel, as will be seen, can be thought of as a superset of
containers.
source: IBM
A container is a named holder of information – with no CICS
imposed limitations on how big it can be (albeit it with some
potential z/OS caveats when it really starts to ‘push the
envelope’). CICS also does not dictate the data formats used within
a container. Thus the data formats used within a container are
entirely application-specific.
A channel, on the other hand, is a named group of containers
– with no CICS imposed limits as to the number of containers that
may appear within a channel. Channels, in serial mode [i.e. one at
a time], are what gets transferred between CICS applications via
this new API. Channels and COMMAREA are, however, mutually exclusive – meaning that
applications can’t opt to use both schemes in parallel.
You can share
your views with me at: anu@guruge.com
© IT In-Depth & Anura Guruge, 2005
|
