You are on page 1of 41

1

BTS for Dummies
(and SHARE attendees!)
Ian J Mitchell, CICS TS for z/OS
Architect, IBM Hursley
ianj_mitchell@uk.ibm.com
15
th
August 2006, Session 1036
2
What's this session about?
Review of CICS Business Transaction Services
capabilities
– Form, function, style,...
What's going on under the covers?
– Repository files
– The Local Request Queue
– BTS's unique failure notification capability
Summary
3
Review of CICS Business Transaction
Services
4
CICS BTS History
Introduced in CICS TS 1.3
Exploited as the run-time for Service Flow Runtime
(and MQ Integrator Agent for CICS)
Basis for the SOAP for CICS Supportpac and
Feature
Pioneered the Container-based programming
– Now realised in v3.1 with channels
– Basis for v3.1 Web services pipeline
Significant additional IBM capabilities are built on the CICS BTS API
and its facilities.
Not all the power of the BTS API has been exploited by these
projects. For example, none has, so far, used parallel execution.
It's becoming easier to exploit BTS via these higher-level capabilities,
but your own application requirements might require programming the
API in your own style.
5
CICS BTS Objectives
Provide CICS services to implement business
transactions
Make these services:
Recoverable, robust, sysplex-enabled
Supply an environment which:
is scaleable
tolerates region failures
supports continuous operations
integrates with system management
Most real-world applications are business transactions – more
complex than one single atomic transaction.
But the coordination of the pieces of the business transaction is
normally the responsibility of the application developer, and it is very
easy to mix up the logic and data controlling the application progress
and flow with the core enterprise logic and data.
This makes the application components far harder to reuse since the
core function is 'polluted' by control responsibilities.
The aim of BTS is to allow the control logic and data to be clearly
separated from reusable business components. At the same time, the
BTS environment naturally promotes best practices for scalability and
is integrated with the system management tools provided by CICS
Transaction Server.
6
Evolutionary within the CICS environment
Extend the CICS API
Familiar to application developers
Servicability characteristics (CECI, EDF, Trace
etc)
Supply useful primitives in terms of familiar objects
The functions of BTS are exposed in a style that is familiar to CICS
application programmers – via the EXEC API.
A BTS application is made up from very familiar objects –
transactions, tasks – put together in new ways by the BTS
infrastructure.
New abstractions are introduced and will now be explained and
discussed. Many of these abstractions are actually simply
formalisations of concepts that most programmers will be familiar with.
7
CICS transactions vs Business
Transactions
CICS Transaction
The basic CICS application building block
Contains one or more UOWs
Typically short-lived and associated with a terminal
May be tied together to form a pseudo-conversation
Business Transaction
Implements a complete business function
Typically made of several parts (activities)
Typically long-lived
Characteristic of eBusiness:
Client server applications
Web interface applications
System management applications
8
Business Transactions
Today's CICS applications are business transactions
Each activity is mapped to a CICS transaction
Programs contain both control logic and business logic
Control data in many files (mixed with business data)
The working storage of the business transaction
Can introduce affinities
Packages attempt to support long-lived, multi-
transaction, applications
Contain lots of 'system level' or 'infrastructure' code
Pollutes the core function, inhibites reuse
9
What BTS provides
A business application model
Significant extensions to the CICS API
Synchronous and asynchronous processing
Event-driven control
A framework for control logic
Encourages the production of reusable business logic
A robust, scalable environment
Extends the ACID transaction semantics
Sysplex enabled
Workload balancing


10
New Objects
• Application Objects
• Process
• Activity
• Container
• Event
• Timer
• System Programmer Objects
• Process type
• Repository Files
• Local Request Queue
11
CICS BTS application concepts –
processes and activities
Process
Activity
Activation
(transaction)
Process
End to end business update
Activities
reusable business
functions
Process
An instance of a process type
e.g. holiday booking for Fred Bloggs Summer 2006
Has a unique name, to be determined by the application
e.g. booking reference number
Made up of activities
Activity
Encapsulates part of a process
A sequence of one or more activations
where each activation is a CICS transaction
May execute synchronously or asynchronously
Implements either:
a business function (business activity)
control logic (control activity)
(perhaps both)
Activities are :
12
CICS BTS application concepts -
containers
Containers
Process
End to end business update
Activities
reusable business
functions
Containers
stores for application
control data and
business function
parameters
An Activity is made up of...
definitional attributes
Tranid, Program, Userid, Completion Event Name
associated activity containers, events
references to children
A Process is made up of...
reference to the root activity
associated process containers
Stored as a record (or records) in VSAM KSDSs – Repository Files
accessed on-line via CICS File Control
readable via off-line utility program
Containers
Used for passing business data between activities (and activations)
Like a named commareas, but:
there may be several
no 32K limit
13
CICS BTS application concepts –
events and timers
Timer
Events
Events
signals of progress in the
business
functions
Timers
simple event signallers
for the passage of time
Events
A named control signal
used to signal progress in the application
Initially not-fired
Events are fired when:
a RUN command is issued (input event)
an activity completes (activity completion event)
a defined timer expires (timer event)
Can define composite events
with an 'and' or 'or' predicate
Timers
A named interval or date/time
Has an associated event
Associated event fires when timer expires
Time: hours/minutes/seconds
Date: year/month/dayofmonth or year/dayofyear
Interval: days/hours/minutes/seconds
14
CICS BTS application concepts –
transaction scope
Invoking (activating) Activities
signals progress
Synchronous activation
LINK – same tran
Activities do things by being 'activated'. This is just a new term for
executed. The new term is used to distinguish BTS program execution
from simple transaction execution. An activation is event-driven and
uses containers for input, output and state management.
There are three ways to activate an activity program:
• Link
• Run Sync
• Run Async
Link
EXEC CICS LINK ACTIVITY is just like EXEC CICS LINK PROGRAM
under the covers!
The activation of the 'parent' invokes the 'child' within the same task
and this extends the program 'stack'.
15
CICS BTS application concepts –
transaction scope
Invoking (activating) Activities
signals progress
Synchronous activation
LINK – same tran
RUN – separate tran
new tranid/userid
RUN SYNC
This method of activating an activity program can be used to change
the security context or transid, but the parent is suspended and blocks
awaiting control to be returned from the EXEC CICS RUN SYNC
command.
Under the covers, a second task is attached and runs the child.
The activation of the child may fail and roll-back independently of the
parent, but the child can only commit if the parent's activation
commits.
16
Invoking (activating) Activities
signals progress
Synchronous activation
LINK – same tran
RUN – separate tran
new tranid/userid
Asynchronous activation
separate tran
event signals completion
Can run multiple activities in
parallel
CICS BTS application concepts –
transaction scope
RUN ASYNC
This method of activation is very much like 'START TRAN PROTECT'.
However, where 'START TRAN PROTECT' is “fire-and-forget”, RUN
ASYNC uses BTS events to ensure that the parent activity can
'rendezvous' with the completion of the child.
The EXEC CICS RUN ASYNC command requests a future activation
of the process or activity. The future activation is recoverable, that is,
it will only occur if the requesting transaction commits.
Any activity can have multiple children, and any number of those
children can be “RUN SYNC'd” at the same time. Each async
activation of a child will eventually lead to a completion event
awakening the parent once the child completes.


17
Process types, repository files and the
local request queue
• Process Type
• Defined via RDO
• The 'transaction definition' for a business transaction
• e.g. travel booking, patient admission, course enrollment
• Defines certain attributes associated with the business transaction
• e.g. name of the associated repository file, the name of an audit trail
• Can enable/disable a process type
• Useful search key
• Repository files
• VSAM KSDS
• Stores the state of processes and activities
• Flexible mapping from types to files
• One-to-one or many-to-one
• Local Request Queue
• Stores pending events
• Receives events dispatched from other regions
• Combines with the system log to ensure notification of failure
ProcessTypes
Process types are the equivalent of the transaction definition for BTS.
Repository Files
You may define as few or as many repository files as needed.
Separate ones may be needed to support the level of IO activity
generated by a workload (the repositories are updated every time an
activation is dispatched), or because different applications require
their own back-up and security policies.
Each CICS region to which activations can be dispatched will need
access to the appropriate repository file. This sharing can be via
VSAM RLS or CICS function-shipping.
Local Request Queues
Each region has its own LRQ (they must not be shared).
18
What is a CICS BTS Process?
A Process is not a
Server
A Process should not
'be' anything
A Process should not be
permanent
A Process need not only
involve single agents
A Process should
provide a Service
A Process's purpose is
to do something
A Process should have
a limited lifespan
A Process should
implement a business
procedure
19
What is a CICS BTS Process?
A Process is not a
Server
State should be limited to that needed
to control individual business
transactions
A Process should not
'be' anything
not a permanent representation of
some business object or enterprise
data
A Process should not be
permanent
remember, it's not a server or object!
A Process need not only
involve single agents
it should involve whoever and whatever
is in the 'real' process
A Process should
provide a Service
to implement a business process
A Process's purpose is
to do something
to make changes to enterprise data
determined by the business
transaction
A Process should have
a limited lifespan
to enable simpler change management
A Process should
implement a business
procedure
coordinate the input and actions of
multiple participating agents
20
Programming a pseudo-conversation
+--------> EXEC CICS RECEIVE MAP
|
| EXEC CICS ADDRESS COMMAREA
|
| select(some_state)
| when(first_time)
| :
loop controlled ! do first step
by CICS via :
the terminal when(xxxx)
| :
| ! do step xxxx
| :
| when(finished)
| :
| ! do final step
| :
| end select
|
| Update commarea
|
| EXEC CICS SEND MAP
|
+--------- EXEC CICS RETURN

This simple pattern enables a single program to handle multiple
events from a terminal as a pseudo-conversation progresses.
The program expects to get executed each time the user interacts
with the terminal. The user supplies input and signals progress. The
program executes and discovers what to do next from the input and
the pseudo-conversational state in a commarea.
It's as if there is a loop wrapped around the program – this loop is
provided by CICS.
21
Comparing a pseudo-conversational
program to an activity program
+--------> EXEC CICS RECEIVE MAP
|
| EXEC CICS ADDRESS COMMAREA
|
| select(some_state)
| when(first_time)
| :
loop controlled ! do first step
by CICS via :
the terminal when(xxxx)
| :
| ! do step xxxx
| :
| when(finished)
| :
| ! do final step
| :
| end select
|
| Update commarea
|
| EXEC CICS SEND MAP
|
+--------- EXEC CICS RETURN

+--------> EXEC CICS RETRIEVE REATTACH EVENT
|
| EXEC CICS GET CONTAINER
|
| select(event)
| when('DFHINITIAL')
| :
loop controlled ! do first step
by CICS via :
the Activity when(xxxx)
and events :
| ! do step xxxx
| :
| when(finished)
| :
| ! do final step
| :
| end select
|
|
|
| EXEC CICS PUT CONTAINER
|
+--------- EXEC CICS RETURN
The same pattern is used as the basis for a 'BTS program' – there's
actually nothing that defines a BTS program.
In the BTS case, the events are more explicit and so is the persistent
state associated with the activity.
In the same way, CICS provides a loop that re-drives the simple logic
of the program.
This can also be regarded as the classic event-processing-loop
present in the client GUI programming model.
22
“Hello World” - BTS Style
EXEC CICS DEFINE PROCESS(“Simple Process”)
TRANSID(...)
PROGRAM(“HELLOW”);
EXEC CICS PUT ACQPROCESS CONTAINER(“MSG”)
FROM(“HELLO WORLD”);
EXEC CICS RUN ACQPROCESS ASYNC;

EXEC CICS RETRIEVE REATTACH EVENT(event)

select(event)
when('DFHINITIAL')
EXEC CICS GET CONTAINER(“MSG”)
INTO(message);
EXEC CICS WRITE FILE(...)
FROM(message);
otherwise ....

end select

EXEC CICS RETURN
Define a process
Pass it a message
Run the process
Get the current event
Determine what to do
Do it!
23
Programming an event-driven Activity
EXEC CICS RETRIEVE REATTACH EVENT

EXEC CICS GET CONTAINER

select(event)
when('DFHINITIAL')
:
EXEC CICS DEFINE ACTIVITY(CHILD1)..
EXEC CICS PUT CONTAINER...
EXEC CICS RUN ACTIVITY ASYNC...
:
when('CHILD1')
:
! do step xxxx
:
when('CHILD2')
:
! do final step
:
end select


EXEC CICS PUT CONTAINER

EXEC CICS RETURN
GrundpurenL AcLIvILy
CIIId1
1. D
¡
H
¡N
¡T
¡A
¡
z
. D
¡
H
¡N
¡T
¡A
¡
CIIIdz
q. D¡H¡N¡T¡A¡
¸. CIIId1 (com
pIeLe)
¸. CIIIdz (compIeLe)
6
.

C
o
m
p
I
e
L
e
PurenL AcLIvILy
1.The first activation of an activity always fires the 'DFHINITIAL' event.
All other events must be created by the activity that expects to handle
them (completion events, input events and timer events).
2.The activity is activated for the first time, defines a child and runs it
async. This fires a second dfhinitial event – on the new activity just
created. The event is dispatched to the new child only when the
current activation commits
3.The child executes and completes (in this case after just a single
activation), and so fires its completion event back in its parent.
4.The completion event of child1 is handled and provokes the
definition and activation of a second child. Again, that child performs
its work and completes in a single async task.
5.The completion of the second child provokes a further activation of
the parent. This time no further activities or events are defined, and so
the parent completes and fires its own completion event.
6.The completion event provokes an activation of the grandparent.
24
Activity State-transition diagram
The normal lifecycle would be to be:
•Created in the initial state,
•Become active via LINK or RUN SYNC
•(a brief dormant phase happens if RUN ASYNC is the first
activation)
•If waiting for another event then the activity goes dormant
•Any event firing will make it active
•When there are no outstanding events left unfired, the activity
is complete
•When its own parent completes, the activity is deleted.
A dormant activity can be canceled. A complete activity can be
reset and reused.
25
Process and Activity lifecycle
• Creation
• EXEC CICS DEFINE PROCESS|ACTIVITY
• Initialisation
• EXEC CICS RUN|LINK PROCESS|ACTIVITY
• Progress
• EXEC CICS RETRIEVE REATTACH EVENT
• External interaction
• EXEC CICS DEFINE INPUT EVENT
• EXEC CICS ACQUIRE PROCESS|ACTIVITY
• Completion
• See next chart...
Process Creation
EXEC CICS DEFINE PROCESS
creates a new process and its root activity
Specifies the attributes of the process
tranid (for activations via RUN)
userid ( " " " " )
programname
Definitional attributes are fixed for the lifetime of the process
static relationship to a program
simplifies the dynamics
one program is responsible for handling the events
Once defined the activity can have data associated with it by the
transaction that creates it.
Activity Creation
EXEC CICS DEFINE ACTIVITY
Dynamically builds the tree of activities in the process
Specifies the attributes of the activity
tranid (for activations via RUN)
userid ( " " " " )
programname
Definitional attributes are fixed for the lifetime of the activity
static relationship to a program
26
Activity Completion
• When an activity completes, its completion event fires
• activity completion is not (necessarily) task end
• having nothing left to do...
• no input events expected,no incomplete children,no unexpired timers
• or failure (transaction abend or rollback)
• even if it abends the completion event is guaranteed to
be fired in the parent
• a (patented) extension to the transaction model
• completion event awakens the parent
• parent examines the state of the completed child
• A process completes when the root activity completes
The root has no parent - nothing (within the process) to inform
It is up to the process to signal what this means to the outside
world
The set of updates is complete
enterprise data is consistent and shows the results of the
business transaction
The working storage of the process is discarded
its purpose has been fulfilled
space freed in the repository file
27
Dealing with failure
Complete, abended
• Even if it abends the completion event is
guaranteed to be fired in the parent
• a (patented) extension to the transaction model
• Extends the transaction logging
• A failed activation completes the activity
• Parent is made aware
• Parent finds out the completion status of the
child
• EXEC CICS CHECK ACTIVITY
• returns failure data from the failing activation
• abend code, abend program
• parent can examine the childs container data as
normal
• Parent is able to decide what to do with the
failure
• for example, perform some compensation
Re-activation
Completion does not mean destruction
Parents can examine completed children
completion status
output container contents
Parents can 'reuse' child for another piece of work
EXEC CICS RESET ACTIVITY
prepares activity for work again
can update container contents
activity will get DFHINITIAL event again
Useful for 'server' processes
Cancelation
EXEC CICS CANCEL ACTIVITY (or PROCESS)
Will force a premature completion of the activity or process
Committed updates from past activations remain
may need to compensate
Activity can then be destroyed or reused
Destruction
The state of associated with a child Activity is deleted from the repository
file when the parent completes
cleans up the repository file as the process proceeds
28
Container-based programming
29
Container-based programming
• Containers can be used instead of COMMAREAs
• Containers do not have 32K limits
• Containers provide loose-coupling between business logic
programs
• Containers allow a greater structuring of the interface
• Containers are garbage-collected by the system
• they have a well defined lifetime.
• Local LINK can pass containers directly from program to
program
Containers are now widespread in the CICS API, not just in BTS.
Containers can be associated with Channels, Processes and
Activities.
Containers are intended to hold data as it is passed from component
to component within an application.
There is a simple core container API – PUT, GET, DELETE, MOVE.
The differences between Process or Activity containers and Channel
containers are due to the lifecycles of the objects to which they
belong.
Processes and Activities are persistent, recoverable and event-driven,
so Process and Activity containers are persistent and recoverable.
Channels are non-persistent and non-recoverable, so Channel
containers are non-persistent and non-recoverable.
30
Container-base programming with BTS
Program “PAYR”
! get the employee passed into this program
EXEC CICS GET CONTAINER('employee') INTO(emp)
:
:
! return the status to the caller
EXEC CICS PUT CONTAINER('status') FROM('OK')
DEFINE ACTIVITY('payroll') PROGRAM('payact')
! create the employee container on the payroll interface
EXEC CICS PUT CONTAINER('employee') ACTIVITY('payroll') FROM('Fred Smith')
! create the wage container on the payroll interface
EXEC CICS PUT CONTAINER('wage') ACTIVITY('payroll') FROM('10 pounds')
! invoke the payroll service passing the payroll interface
EXEC CICS LINK ACTIVITY('payroll')
! examine the status returned on the payroll interface
EXEC CICS GET CONTAINER('status') ACTIVITY('payroll') INTO(status)
Program “PAYACT”
EXEC CICS RETRIEVE EVENT(...
WHEN('....
EXEC CICS LINK PROGRAM('payt')
1. Parent activity constructs the
containers and invokes the
child activity.
2. Child activity program handles the events
3. Container-aware business logic performs the function
Separating event-handling from business function, allows easier reuse of the function.
A parent activity can use containers to pass input data to a 'service'
(child) activity.
The service activity, being event-driven, handles the event and links to
a container-based piece of primitive business logic. This piece of logic
expects to receive its input and return its output in containers.
If the activity expects to handle multiple events, then it can use
containers to maintain its own internal state.
31
Container-base programming with BTS
Program “PAYR”
! get the employee passed into this program
EXEC CICS GET CONTAINER('employee') INTO(emp)
:
:
! return the status to the caller
EXEC CICS PUT CONTAINER('status') FROM('OK')
DEFINE ACTIVITY('payroll') PROGRAM('payact')
! create the employee container on the payroll interface
EXEC CICS PUT CONTAINER('employee') ACTIVITY('payroll') FROM('Fred Smith')
! create the wage container on the payroll interface
EXEC CICS PUT CONTAINER('wage') ACTIVITY('payroll') FROM('10 pounds')
! invoke the payroll service passing the payroll interface
EXEC CICS LINK ACTIVITY('payroll')
! examine the status returned on the payroll interface
EXEC CICS GET CONTAINER('status') ACTIVITY('payroll') INTO(status)
Program “PAYACT”
EXEC CICS RETRIEVE EVENT(...
WHEN('....
EXEC CICS LINK PROGRAM('payr')
+÷+´*÷ ¤÷¬´*´¬*+!O¤lOOBB!· .=×<=¤¬+!O
· +O+¤Y+ Y++ +¯OBOl++ +OBY¤<B+O OB Y++
÷*÷÷ ÷´÷¬ .*¬ ÷×*¬¤´*÷=+!+¯OBOl++!· ¤
· +O+¤Y+ Y++ I¤++ +OBY¤<B+O OB Y++ O¤lOO
÷*÷÷ ÷´÷¬ .*¬ ÷×*¬¤´*÷=+!I¤++!· ¤÷¬´*
· <B+O×+ Y++ O¤lOOBB A+O+<++ O¤AA<B+ Y+
÷*÷÷ ÷´÷¬ *´*¬ ¤÷¬´*´¬*+!O¤lOOBB!·
· +'¤¯<B+ Y++ AY¤Y4A O+Y4OB++ OB Y++ O¤l
÷*÷÷ ÷´÷¬ <÷¬ ÷×*¬¤´*÷=+!AY¤Y4A!· ¤÷
.OO+O¤¯ .¤*¤÷¬
÷*÷÷ ÷´÷¬ =÷¬=´÷*÷ ÷*÷*¬
*¬÷*+!
÷*÷÷ ÷´÷¬ *´*¬ .=×<=¤¬+
4. Another application has its own events, but can
easily reuse the business logic by
using the same containers.
The same piece of container-based primitive business logic can
equally be reused in other process types. The only contract it has with
its caller is the set of events and the names (and formats) of the
containers.
Equally it can be linked to, having a channel passed to it. The core
container commands it uses will detect whether the containers
referred to belong to the current activity or the current channel of the
task.
32
Constructing applications from container-
based components
Program “PAYR”
! get the employee passed into this program
EXEC CICS GET CONTAINER('employee') INTO(emp)
:
! return the status to the caller
EXEC CICS PUT CONTAINER('status') FROM('OK')
Program “cust”
! get the customer passed into this program
EXEC CICS GET CONTAINER('customer-name') INTO(cust)
:
! return the status to the caller
EXEC CICS PUT CONTAINER('status') FROM('OK')
Program “stock”
! get the stock item passed into this program
EXEC CICS GET CONTAINER('serial-number') INTO(serial)
:
! return the status to the caller
EXEC CICS PUT CONTAINER('status') FROM('OK')
DEFINE ACTIVITY('payroll') PROGRAM('payact')
! create the employee container on the payroll interface
EXEC CICS PUT CONTAINER('employee') ACTIVITY('payroll') FROM('Fred Smith')
! create the wage container on the payroll interface
EXEC CICS PUT CONTAINER('wage') ACTIVITY('payroll') FROM('10 pounds')
! invoke the payroll service passing the payroll interface
EXEC CICS LINK ACTIVITY('payroll')
! examine the status returned on the payroll interface
EXEC CICS GET CONTAINER('status') ACTIVITY('payroll') INTO(status)
Program “PAYACT”
EXEC CICS RETRIEVE EVENT(...
WHEN('....
EXEC CICS LINK PROGRAM('payr')
DEFINE ACTIVITY('payroll') PROGRAM('payact')
! create the employee container on the payroll interface
EXEC CICS PUT CONTAINER('employee') ACTIVITY('payroll') FROM('Fred Smith')
! create the wage container on the payroll interface
EXEC CICS PUT CONTAINER('wage') ACTIVITY('payroll') FROM('10 pounds')
! invoke the payroll service passing the payroll interface
EXEC CICS LINK ACTIVITY('payroll')
! examine the status returned on the payroll interface
EXEC CICS GET CONTAINER('status') ACTIVITY('payroll') INTO(status)
DEFINE ACTIVITY('payroll') PROGRAM('payact')
! create the employee container on the payroll interface
EXEC CICS PUT CONTAINER('employee') ACTIVITY('payroll') FROM('Fred Smith')
! create the wage container on the payroll interface
EXEC CICS PUT CONTAINER('wage') ACTIVITY('payroll') FROM('10 pounds')
! invoke the payroll service passing the payroll interface
EXEC CICS LINK ACTIVITY('payroll')
! examine the status returned on the payroll interface
EXEC CICS GET CONTAINER('status') ACTIVITY('payroll') INTO(status)
Program “CUSTACT”
EXEC CICS RETRIEVE EVENT(...
WHEN('....
EXEC CICS LINK PROGRAM('payr')
DEFINE ACTIVITY('payroll') PROGRAM('payact')
! create the employee container on the payroll interface
EXEC CICS PUT CONTAINER('employee') ACTIVITY('payroll') FROM('Fred Smith')
! create the wage container on the payroll interface
EXEC CICS PUT CONTAINER('wage') ACTIVITY('payroll') FROM('10 pounds')
! invoke the payroll service passing the payroll interface
EXEC CICS LINK ACTIVITY('payroll')
! examine the status returned on the payroll interface
EXEC CICS GET CONTAINER('status') ACTIVITY('payroll') INTO(status)
Multitude of event-driven applications
Assembled from core pieces of container-based business logic primatives
Program “STOCKACT”
EXEC CICS RETRIEVE EVENT(...
WHEN('....
EXEC CICS LINK PROGRAM('payr')
High-level, controlling activity programs Low-level (leaf) activity programs
A suite of programs using BTS would be a mixture of primitive
container-based business logic, and some event-driven 'controllers'
that utilise these primitives in interesting ways.
33
Documentation sources
• Manual - CICS Business Transaction Services
• document Number SC34-5268
• BTS Application Programming Guide material
• Sample Application description
• BTS API Reference
• Redbook - Business Process Model Implementation with CICS
Business Transaction Services
• document number SG24-5464 (See www.redbooks.ibm.com)
• Descriptions of three complete applications
• Application Architecture advice
• Setup and System Management advice
• Sample Application Source shipped with the product
• order-entry type application
• SupportPac CA1L
34
Summary
• Business Transaction Services provides powerful extensions to
the CICS programming model.
• BTS is being exploited by IBM in the provision of major
application transformation enablers
• Service Flow Runtime
• SOAP for CICS
• BTS continues to be enhanced.
• Providing unique features
35
New options in CICS TS v2 and v3.1
36
CICS BTS enhancements
Introduced primarily to support the SOAP for CICS
Feature
Included in the base for CICS TS 2.3 and v3.1
Available via PTF for CICS TS 2.2
PTF for APAR PQ76073
Performance optimization for simple container-
based applications
Usability for GET CONTAINER INTO
New MOVE container command
37
NOCHECK on DEFINE PROCESS
• Avoids use of repository file for simple, single-task processes
• Container-based applications using only LINK or RUN SYNC complete in a
single task.
• No need to reserve process-name, no need to harden any container or event
state.
• NOCHECK option will delay/eliminate writing to repository file.
• Eliminate for the simple case of a process completing normally in a single
task
• Delay until syncpoint if the process does not complete normally
• Significant pathlength and response time improvements for simple BTS
applications
• For example, the SOAP for CICS Feature pipeline.
Unnecessary when using Channel Containers in v3
38
NODATA on GET CONTAINER
Applications are normally required to know the
shape of their containers.
LENGERR raised on GET INTO unless the length
is precisely correct.
NODATA option will return the length of the data in
the container without requiring a buffer and suffering
a LENGERR.
EXEC CICS GET CONTAINER(“xml-request”) FLENGTH(len) NODATA;
EXEC CICS GETMAIN FLENGTH(len);
EXEC CICS GET CONTAINER(“xml-request”) INTO(request-data);
39
MOVE container
Passing containers from one activity to another can
be useful, but tiresome and inefficient.
MOVE CONTAINER achieve the same result with
one command and no temporary buffer required.
EXEC CICS GET CONTAINER(“xml-request”) ACTIVITY(“transport”) SET(req-pointer);
EXEC CICS PUT CONTAINER(“xml-request”) ACTIVITY(“header-parser”) FROM(req);
EXEC CICS DELETE CONTAINER(“xml-request”) ACTIVITY(“transport”);
EXEC CICS MOVE CONTAINER(“xml-request”) FROMACTIVITY(“transport”)
TOACTIVITY(“header-parser”) AS(“xml-request”);


40
Any Questions?


41
Thank You for your Attention
Please fill out a session evaluation form

What's this session about?
Review of CICS Business Transaction Services capabilities – Form, function, style,... What's going on under the covers? – Repository files – The Local Request Queue – BTS's unique failure notification capability Summary

2

Review of CICS Business Transaction Services

3

CICS BTS History
Introduced in CICS TS 1.3 Exploited as the run-time for Service Flow Runtime (and MQ Integrator Agent for CICS) Basis for the SOAP for CICS Supportpac and Feature Pioneered the Container-based programming – Now realised in v3.1 with channels – Basis for v3.1 Web services pipeline

4

Significant additional IBM capabilities are built on the CICS BTS API and its facilities. Not all the power of the BTS API has been exploited by these projects. For example, none has, so far, used parallel execution. It's becoming easier to exploit BTS via these higher-level capabilities, but your own application requirements might require programming the API in your own style.

sysplex-enabled Supply an environment which: is scaleable tolerates region failures supports continuous operations integrates with system management 5 Most real-world applications are business transactions – more complex than one single atomic transaction. But the coordination of the pieces of the business transaction is normally the responsibility of the application developer. . robust.CICS BTS Objectives Provide CICS services to implement business transactions Make these services: Recoverable. The aim of BTS is to allow the control logic and data to be clearly separated from reusable business components. This makes the application components far harder to reuse since the core function is 'polluted' by control responsibilities. and it is very easy to mix up the logic and data controlling the application progress and flow with the core enterprise logic and data. At the same time. the BTS environment naturally promotes best practices for scalability and is integrated with the system management tools provided by CICS Transaction Server.

EDF. Many of these abstractions are actually simply formalisations of concepts that most programmers will be familiar with. tasks – put together in new ways by the BTS infrastructure. Trace etc) Supply useful primitives in terms of familiar objects 6 The functions of BTS are exposed in a style that is familiar to CICS application programmers – via the EXEC API.Evolutionary within the CICS environment Extend the CICS API Familiar to application developers Servicability characteristics (CECI. A BTS application is made up from very familiar objects – transactions. New abstractions are introduced and will now be explained and discussed. .

CICS transactions vs Business Transactions CICS Transaction The basic CICS application building block Contains one or more UOWs Typically short-lived and associated with a terminal May be tied together to form a pseudo-conversation Business Transaction Implements a complete business function Typically made of several parts (activities) Typically long-lived Characteristic of eBusiness: Client server applications Web interface applications System management applications 7 .

Business Transactions Today's CICS applications are business transactions Each activity is mapped to a CICS transaction Programs contain both control logic and business logic Control data in many files (mixed with business data) The working storage of the business transaction Can introduce affinities Packages attempt to support long-lived. multitransaction. applications Contain lots of 'system level' or 'infrastructure' code Pollutes the core function. inhibites reuse 8 .

scalable environment Extends the ACID transaction semantics Sysplex enabled Workload balancing 9 .What BTS provides A business application model Significant extensions to the CICS API Synchronous and asynchronous processing Event-driven control A framework for control logic Encourages the production of reusable business logic A robust.

New Objects • Application Objects • • • • • Process Activity Container Event Timer • System Programmer Objects • Process type • Repository Files • Local Request Queue 10 .

holiday booking for Fred Bloggs Summer 2006 Has a unique name.g.g. to be determined by the application e.CICS BTS application concepts – processes and activities Process End to end business update Activities reusable business functions Activation (transaction) Process Activity 11 Process An instance of a process type e. booking reference number Made up of activities Activity Encapsulates part of a process A sequence of one or more activations where each activation is a CICS transaction May execute synchronously or asynchronously Implements either: a business function (business activity) control logic (control activity) (perhaps both) Activities are : .

. reference to the root activity associated process containers Stored as a record (or records) in VSAM KSDSs – Repository Files accessed on-line via CICS File Control readable via off-line utility program Containers Used for passing business data between activities (and activations) Like a named commareas.. events references to children A Process is made up of. but: there may be several no 32K limit . definitional attributes Tranid. Program.. Userid. Completion Event Name associated activity containers..CICS BTS application concepts containers Process End to end business update Activities Containers reusable business functions Containers stores for application control data and business function parameters 12 An Activity is made up of.

CICS BTS application concepts – events and timers Events signals of progress in the business functions Timers simple event signallers for the passage of time Events Timer 13 Events A named control signal used to signal progress in the application Initially not-fired Events are fired when: a RUN command is issued (input event) an activity completes (activity completion event) a defined timer expires (timer event) Can define composite events with an 'and' or 'or' predicate Timers A named interval or date/time Has an associated event Associated event fires when timer expires Time: hours/minutes/seconds Date: year/month/dayofmonth or year/dayofyear Interval: days/hours/minutes/seconds .

The new term is used to distinguish BTS program execution from simple transaction execution. This is just a new term for executed. output and state management. An activation is event-driven and uses containers for input.CICS BTS application concepts – transaction scope Invoking (activating) Activities signals progress Synchronous activation LINK – same tran 14 Activities do things by being 'activated'. . There are three ways to activate an activity program: • Link • Run Sync • Run Async Link EXEC CICS LINK ACTIVITY is just like EXEC CICS LINK PROGRAM under the covers! The activation of the 'parent' invokes the 'child' within the same task and this extends the program 'stack'.

. The activation of the child may fail and roll-back independently of the parent. but the child can only commit if the parent's activation commits.CICS BTS application concepts – transaction scope Invoking (activating) Activities signals progress Synchronous activation LINK – same tran RUN – separate tran new tranid/userid 15 RUN SYNC This method of activating an activity program can be used to change the security context or transid. a second task is attached and runs the child. but the parent is suspended and blocks awaiting control to be returned from the EXEC CICS RUN SYNC command. Under the covers.

that is. The EXEC CICS RUN ASYNC command requests a future activation of the process or activity. where 'START TRAN PROTECT' is “fire-and-forget”. RUN ASYNC uses BTS events to ensure that the parent activity can 'rendezvous' with the completion of the child. However. it will only occur if the requesting transaction commits. Any activity can have multiple children. . and any number of those children can be “RUN SYNC'd” at the same time. The future activation is recoverable. Each async activation of a child will eventually lead to a completion event awakening the parent once the child completes.CICS BTS application concepts – transaction scope Invoking (activating) Activities signals progress Synchronous activation LINK – same tran RUN – separate tran new tranid/userid Asynchronous activation separate tran event signals completion Can run multiple activities in parallel 16 RUN ASYNC This method of activation is very much like 'START TRAN PROTECT'.

repository files and the local request queue • Process Type • Defined via RDO • The 'transaction definition' for a business transaction • e. This sharing can be via VSAM RLS or CICS function-shipping. Local Request Queues Each region has its own LRQ (they must not be shared).g. travel booking.Process types. Repository Files You may define as few or as many repository files as needed. or because different applications require their own back-up and security policies. patient admission. . name of the associated repository file. Separate ones may be needed to support the level of IO activity generated by a workload (the repositories are updated every time an activation is dispatched). the name of an audit trail • Useful search key • Can enable/disable a process type • Repository files • VSAM KSDS • Stores the state of processes and activities • Flexible mapping from types to files • One-to-one or many-to-one • Local Request Queue • Stores pending events • Receives events dispatched from other regions • Combines with the system log to ensure notification of failure 17 ProcessTypes Process types are the equivalent of the transaction definition for BTS. course enrollment • Defines certain attributes associated with the business transaction • e. Each CICS region to which activations can be dispatched will need access to the appropriate repository file.g.

What is a CICS BTS Process? A Process is not a Server A Process should not 'be' anything A Process should not be permanent A Process need not only involve single agents A Process should provide a Service A Process's purpose is to do something A Process should have a limited lifespan A Process should implement a business procedure 18 .

What is a CICS BTS Process? A Process is not a Server State should be limited to that needed to control individual business transactions A Process should provide a Service to implement a business process A Process should not 'be' anything not a permanent representation of some business object or enterprise data A Process's purpose is to do something to make changes to enterprise data determined by the business transaction A Process should not be permanent remember. it's not a server or object! A Process should have a limited lifespan to enable simpler change management A Process need not only involve single agents it should involve whoever and whatever is in the 'real' process A Process should implement a business procedure coordinate the input and actions of multiple participating agents 19 .

The user supplies input and signals progress.EXEC CICS RETURN 20 This simple pattern enables a single program to handle multiple events from a terminal as a pseudo-conversation progresses. The program expects to get executed each time the user interacts with the terminal. .Programming a pseudo-conversation +--------> EXEC CICS RECEIVE MAP | | EXEC CICS ADDRESS COMMAREA | | select(some_state) | when(first_time) | : loop controlled ! do first step by CICS via : the terminal when(xxxx) | : | ! do step xxxx | : | when(finished) | : | ! do final step | : | end select | | Update commarea | | EXEC CICS SEND MAP | +--------. It's as if there is a loop wrapped around the program – this loop is provided by CICS. The program executes and discovers what to do next from the input and the pseudo-conversational state in a commarea.

CICS provides a loop that re-drives the simple logic of the program.EXEC CICS RETURN 21 The same pattern is used as the basis for a 'BTS program' – there's actually nothing that defines a BTS program.EXEC CICS RETURN +--------> EXEC CICS RETRIEVE REATTACH EVENT | | EXEC CICS GET CONTAINER | | select(event) | when('DFHINITIAL') | : loop controlled ! do first step by CICS via : the Activity when(xxxx) and events : | ! do step xxxx | : | when(finished) | : | ! do final step | : | end select | | | | EXEC CICS PUT CONTAINER | +--------. . This can also be regarded as the classic event-processing-loop present in the client GUI programming model. In the BTS case. the events are more explicit and so is the persistent state associated with the activity.Comparing a pseudo-conversational program to an activity program +--------> EXEC CICS RECEIVE MAP | | EXEC CICS ADDRESS COMMAREA | | select(some_state) | when(first_time) | : loop controlled ! do first step by CICS via : the terminal when(xxxx) | : | ! do step xxxx | : | when(finished) | : | ! do final step | : | end select | | Update commarea | | EXEC CICS SEND MAP | +--------. In the same way.

EXEC CICS RETRIEVE REATTACH EVENT(event) select(event) when('DFHINITIAL') EXEC CICS GET CONTAINER(“MSG”) INTO(message).. EXEC CICS RUN ACQPROCESS ASYNC. otherwise .. EXEC CICS PUT ACQPROCESS CONTAINER(“MSG”) FROM(“HELLO WORLD”).... end select EXEC CICS RETURN Define a process Pass it a message Run the process Get the current event Determine what to do Do it! 22 .) PROGRAM(“HELLOW”). EXEC CICS WRITE FILE(.BTS Style EXEC CICS DEFINE PROCESS(“Simple Process”) TRANSID(.“Hello World” ..) FROM(message)..

EXEC CICS RUN ACTIVITY ASYNC. and so fires its completion event back in its parent. : when('CHILD1') : ! do step xxxx : when('CHILD2') : " ! do final step : end select EXEC CICS PUT CONTAINER EXEC CICS RETURN ! 1.The activity is activated for the first time.. EXEC CICS PUT CONTAINER. 6. 4.. defines a child and runs it async. and so the parent completes and fires its own completion event. that child performs its work and completes in a single async task. All other events must be created by the activity that expects to handle them (completion events.Programming an event-driven Activity $ EXEC CICS RETRIEVE REATTACH EVENT EXEC CICS GET CONTAINER select(event) when('DFHINITIAL') : EXEC CICS DEFINE ACTIVITY(CHILD1). 5.The completion event provokes an activation of the grandparent.. # ! 23 . Again.The first activation of an activity always fires the 'DFHINITIAL' event. This time no further activities or events are defined.. input events and timer events).The completion event of child1 is handled and provokes the definition and activation of a second child.The completion of the second child provokes a further activation of the parent..The child executes and completes (in this case after just a single activation). This fires a second dfhinitial event – on the new activity just created. 2. The event is dispatched to the new child only when the current activation commits 3.

A complete activity can be reset and reused. the activity is deleted. A dormant activity can be canceled.Activity State-transition diagram 24 The normal lifecycle would be to be: •Created in the initial state. •Become active via LINK or RUN SYNC •(a brief dormant phase happens if RUN ASYNC is the first activation) •If waiting for another event then the activity goes dormant •Any event firing will make it active •When there are no outstanding events left unfired. the activity is complete •When its own parent completes. .

. 25 Process Creation EXEC CICS DEFINE PROCESS creates a new process and its root activity Specifies the attributes of the process tranid (for activations via RUN) userid ( " " " " ) programname Definitional attributes are fixed for the lifetime of the process static relationship to a program simplifies the dynamics one program is responsible for handling the events Once defined the activity can have data associated with it by the transaction that creates it.Process and Activity lifecycle • Creation • EXEC CICS DEFINE PROCESS|ACTIVITY • Initialisation • Progress • EXEC CICS RUN|LINK PROCESS|ACTIVITY • EXEC CICS RETRIEVE REATTACH EVENT • External interaction • EXEC CICS DEFINE INPUT EVENT • EXEC CICS ACQUIRE PROCESS|ACTIVITY • Completion • See next chart. Activity Creation EXEC CICS DEFINE ACTIVITY Dynamically builds the tree of activities in the process Specifies the attributes of the activity tranid (for activations via RUN) userid ( " " " " ) programname Definitional attributes are fixed for the lifetime of the activity static relationship to a program ..

no incomplete children. its completion event fires • activity completion is not (necessarily) task end • having nothing left to do. • no input events expected..no unexpired timers • or failure (transaction abend or rollback) • even if it abends the completion event is guaranteed to be fired in the parent • a (patented) extension to the transaction model • completion event awakens the parent • parent examines the state of the completed child • A process completes when the root activity completes 26 The root has no parent .Activity Completion • When an activity completes..nothing (within the process) to inform It is up to the process to signal what this means to the outside world The set of updates is complete enterprise data is consistent and shows the results of the business transaction The working storage of the process is discarded its purpose has been fulfilled space freed in the repository file .

abended • EXEC CICS CHECK ACTIVITY • returns failure data from the failing activation • abend code. perform some compensation 27 Re-activation Completion does not mean destruction Parents can examine completed children completion status output container contents Parents can 'reuse' child for another piece of work EXEC CICS RESET ACTIVITY prepares activity for work again can update container contents activity will get DFHINITIAL event again Useful for 'server' processes Cancelation EXEC CICS CANCEL ACTIVITY (or PROCESS) Will force a premature completion of the activity or process Committed updates from past activations remain may need to compensate Activity can then be destroyed or reused Destruction The state of associated with a child Activity is deleted from the repository file when the parent completes cleans up the repository file as the process proceeds .Dealing with failure • Even if it abends the completion event is guaranteed to be fired in the parent • a (patented) extension to the transaction model • Extends the transaction logging • A failed activation completes the activity • Parent is made aware • Parent finds out the completion status of the child Complete. abend program • parent can examine the childs container data as normal • Parent is able to decide what to do with the failure • for example.

Container-based programming 28 .

so Channel containers are non-persistent and non-recoverable. GET. Channels are non-persistent and non-recoverable. not just in BTS. • Local LINK can pass containers directly from program to program 29 Containers are now widespread in the CICS API. . recoverable and event-driven.Container-based programming • Containers can be used instead of COMMAREAs • Containers do not have 32K limits • Containers provide loose-coupling between business logic programs • Containers allow a greater structuring of the interface • Containers are garbage-collected by the system • they have a well defined lifetime. Processes and Activities are persistent. Containers are intended to hold data as it is passed from component to component within an application. Processes and Activities. The differences between Process or Activity containers and Channel containers are due to the lifecycles of the objects to which they belong. There is a simple core container API – PUT. MOVE. DELETE. so Process and Activity containers are persistent and recoverable. Containers can be associated with Channels.

Container-aware business logic performs the function Program “PAYR” ! get the employee passed into this program EXEC CICS GET CONTAINER('employee') INTO(emp) : : ! return the status to the caller EXEC CICS PUT CONTAINER('status') FROM('OK') Separating event-handling from business function..Container-base programming with BTS DEFINE ACTIVITY('payroll') PROGRAM('payact') ! create the employee container on the payroll interface EXEC CICS PUT CONTAINER('employee') ACTIVITY('payroll') FROM('Fred Smith') ! create the wage container on the payroll interface EXEC CICS PUT CONTAINER('wage') ACTIVITY('payroll') FROM('10 pounds') ! invoke the payroll service passing the payroll interface EXEC CICS LINK ACTIVITY('payroll') ! examine the status returned on the payroll interface EXEC CICS GET CONTAINER('status') ACTIVITY('payroll') INTO(status) 1.. 2.. EXEC CICS LINK PROGRAM('payt') 3.. WHEN('. handles the event and links to a container-based piece of primitive business logic. then it can use containers to maintain its own internal state. Child activity program handles the events Program “PAYACT” EXEC CICS RETRIEVE EVENT(. 30 A parent activity can use containers to pass input data to a 'service' (child) activity. The service activity. Parent activity constructs the containers and invokes the child activity. being event-driven. This piece of logic expects to receive its input and return its output in containers. allows easier reuse of the function. If the activity expects to handle multiple events.. .

The only contract it has with its caller is the set of events and the names (and formats) of the containers. having a channel passed to it.. Equally it can be linked to. The core container commands it uses will detect whether the containers referred to belong to the current activity or the current channel of the task. Another application has its own events. P52Avw Program “PAYR” ! get the employee passed into this program EXEC CICS GET CONTAINER('employee') INTO(emp) : : ! return the status to the caller EXEC CICS PUT CONTAINER('status') FROM('OK') 2Q20 060F 96A8 CEB4E@v 31 The same piece of container-based primitive business logic can equally be reused in other process types...Container-base programming with BTS DEFINE ACTIVITY('payroll') PROGRAM('payact') 1236A2 0G6I6GRvwË`ƒÌtqqwu CEB4E@vwË ! create the employee container on the payroll interface EXEC CICS PUT CONTAINER('employee') ACTIVITY('payroll') FROM('Fred Smith') ! create the wage container on the payroll interface EXEC CICS PUT CONTAINER('wage') ACTIVITY('payroll') FROM('10 pounds') ! invoke the payroll service passing the payroll interface EXEC CICS LINK ACTIVITY('payroll') ! examine the status returned on the payroll interface EXEC CICS GET CONTAINER('status') ACTIVITY('payroll') INTO(status) ¡ bÌd`wd wgd drËqtƒdd btsw`hsdÌ ts wgd 2Q20 060F CHG 0BAG6A2EvwdrËqtƒddwu  ¡ bÌd`wd wgd `fd btsw`hsdÌ ts wgd Ë`ƒÌt 2Q20 060F CHG 0BAG6A2Evw`fdwu 0G6I ¡ hsytpd wgd Ë`ƒÌtqq vdÌyhbd Ë`vvhsf wg 2Q20 060F 96A8 0G6I6GRvwË`ƒÌtqqwu ¡ d‚`rhsd wgd vw`wxv ÌdwxÌsdc ts wgd Ë`ƒ 2Q20 060F 42G 0BAG6A2Evwvw`wxvwu 0 Program “PAYACT” EXEC CICS RETRIEVE EVENT(. but can CÌtfÌ`r CR0G easily reuse the business logic by 2Q20 060F E2GE62I2 2I2AG using the same containers. EXEC CICS LINK PROGRAM('payr') 4.. WHEN('.. .

Program “CUSTACT” WHEN('......... controlling activity programs Low-level (leaf) activity programs Assembled from core pieces of container-based business logic primatives Program “PAYR” ! get the employee passed into this program EXEC CICS GET CONTAINER('employee') INTO(emp) : ! return the status to the caller EXEC CICS PUT CONTAINER('status') FROM('OK') Program “cust” ! get the customer passed into this program EXEC CICS GET CONTAINER('customer-name') INTO(cust) : ! return the status to the caller EXEC CICS PUT CONTAINER('status') FROM('OK') Program “stock” ! get the stock item passed into this program EXEC CICS GET CONTAINER('serial-number') INTO(serial) : ! return the status to the caller EXEC CICS PUT CONTAINER('status') FROM('OK') 32 A suite of programs using BTS would be a mixture of primitive container-based business logic. . EXEC CICS RETRIEVE EVENT(.. and some event-driven 'controllers' that utilise these primitives in interesting ways.....Constructing applications from containerbased components DEFINE ACTIVITY('payroll') PROGRAM('payact') ! create the employee containerPROGRAM('payact') DEFINE ACTIVITY('payroll') on the payroll interface EXEC! CICS PUTthe employee container ACTIVITY('payroll') FROM('Fred Smith') create CONTAINER('employee')PROGRAM('payact') DEFINE ACTIVITY('payroll') on the payroll interface ! create CICSwage CONTAINER('employee') ACTIVITY('payroll') FROM('Fred Smith') container on the payroll interface EXEC! the PUTthe employee container on the payroll interface create DEFINE ACTIVITY('payroll') PROGRAM('payact') EXEC! CICS PUTthe wage container on the payroll interface CONTAINER('wage') ACTIVITY('payroll') FROM('10 pounds') create CICS PUT CONTAINER('employee') ACTIVITY('payroll') FROM('Fred Smith') EXEC! create the employee container on the payroll interface ! invoke CICSpayroll service passingACTIVITY('payroll') FROM('10 pounds') EXEC! the PUTthe wage container on the payroll interface CONTAINER('wage') the payroll interface create CICS PUT CONTAINER('employee') ACTIVITY('payroll') FROM('Fred Smith') EXEC EXEC! CICS LINK ACTIVITY('payroll') invoke CICS payroll service passingACTIVITY('payroll') FROM('10 pounds') the payroll interface EXEC! the PUTthe wage container on the payroll interface create CONTAINER('wage') ! examineCICS status returned on the payroll interface the LINK ACTIVITY('payroll') EXEC! invoke the payroll service passing the payroll interface EXEC CICS PUT CONTAINER('wage') ACTIVITY('payroll') FROM('10 pounds') EXEC! CICS GET CONTAINER('status') ACTIVITY('payroll') INTO(status) examineCICS LINK ACTIVITY('payroll') the status returned on the payroll interface EXEC! invoke the payroll service passing the payroll interface EXEC! CICS GET the status returned on the payroll interface CONTAINER('status') ACTIVITY('payroll') INTO(status) examineCICS LINK ACTIVITY('payroll') EXEC EXEC! CICS GET CONTAINER('status') ACTIVITY('payroll') INTO(status) examine the status returned on the payroll interface EXEC CICS GET CONTAINER('status') ACTIVITY('payroll') INTO(status) Multitude of event-driven applications Program “PAYACT” EXEC CICS RETRIEVE EVENT(. EXEC CICS EXEC CICS LINK PROGRAM('payr') WHEN('.. EXEC CICS LINK PROGRAM('payr') High-level. Program “STOCKACT” EXEC CICS LINK PROGRAM('payr') WHEN('.. RETRIEVE EVENT(.

Documentation sources • Manual .redbooks.Business Process Model Implementation with CICS Business Transaction Services • • • • document number SG24-5464 (See www.com) Descriptions of three complete applications Application Architecture advice Setup and System Management advice • Sample Application Source shipped with the product • order-entry type application • SupportPac CA1L 33 .ibm.CICS Business Transaction Services • • • • document Number SC34-5268 BTS Application Programming Guide material Sample Application description BTS API Reference • Redbook .

Summary • Business Transaction Services provides powerful extensions to the CICS programming model. • BTS is being exploited by IBM in the provision of major application transformation enablers • Service Flow Runtime • SOAP for CICS • BTS continues to be enhanced. • Providing unique features 34 .

1 35 .New options in CICS TS v2 and v3.

1 Available via PTF for CICS TS 2.2 PTF for APAR PQ76073 Performance optimization for simple containerbased applications Usability for GET CONTAINER INTO New MOVE container command 36 .CICS BTS enhancements Introduced primarily to support the SOAP for CICS Feature Included in the base for CICS TS 2.3 and v3.

no need to harden any container or event state. • Eliminate for the simple case of a process completing normally in a single task • Delay until syncpoint if the process does not complete normally • Significant pathlength and response time improvements for simple BTS applications • For example.NOCHECK on DEFINE PROCESS • Avoids use of repository file for simple. Unnecessary when using Channel Containers in v3 37 . single-task processes • Container-based applications using only LINK or RUN SYNC complete in a single task. • No need to reserve process-name. • NOCHECK option will delay/eliminate writing to repository file. the SOAP for CICS Feature pipeline.

EXEC CICS GET CONTAINER(“xml-request”) FLENGTH(len) NODATA. LENGERR raised on GET INTO unless the length is precisely correct. NODATA option will return the length of the data in the container without requiring a buffer and suffering a LENGERR. EXEC CICS GETMAIN FLENGTH(len). 38 .NODATA on GET CONTAINER Applications are normally required to know the shape of their containers. EXEC CICS GET CONTAINER(“xml-request”) INTO(request-data).

MOVE CONTAINER achieve the same result with one command and no temporary buffer required. EXEC CICS MOVE CONTAINER(“xml-request”) FROMACTIVITY(“transport”) TOACTIVITY(“header-parser”) AS(“xml-request”). EXEC CICS GET CONTAINER(“xml-request”) ACTIVITY(“transport”) SET(req-pointer). 39 . EXEC CICS DELETE CONTAINER(“xml-request”) ACTIVITY(“transport”). EXEC CICS PUT CONTAINER(“xml-request”) ACTIVITY(“header-parser”) FROM(req). but tiresome and inefficient.MOVE container Passing containers from one activity to another can be useful.

Any Questions? 40 .

Thank You for your Attention Please fill out a session evaluation form 41 .