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. DHNTA
. 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')
++* **+!OlOOBB! .=<=+!O
+O+Y+ Y++ +OBOl++ +OBY<B+O OB Y++
* .* **=+!+OBOl++!
+O+Y+ Y++ I++ +OBY<B+O OB Y++ OlOO
* .* **=+!I++! *
<B+O+ Y++ OlOOBB A+O+<++ OAA<B+ Y+
* ** **+!OlOOBB!
+'<B+ Y++ AYY4A O+Y4OB++ OB Y++ Ol
* < **=+!AYY4A!
.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