Top Banner
1 BTS for Dummies (and SHARE attendees!) Ian J Mitchell, CICS TS for z/OS Architect, IBM Hursley [email protected] 15 th August 2006, Session 1036
41
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Cics Bts Intro

1

BTS for Dummies

(and SHARE attendees!)Ian J Mitchell, CICS TS for z/OS

Architect, IBM Hursley

[email protected]

15th August 2006, Session 1036

Page 2: Cics Bts Intro

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

Page 3: Cics Bts Intro

3

Review of CICS Business Transaction Services

Page 4: Cics Bts Intro

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.

Page 5: Cics Bts Intro

5

CICS BTS Objectives

� Provide CICS services to implement business transactions

� Make these services:Recoverable, robust, sysplex-enabled

� Supply an environment which:is scaleabletolerates region failuressupports continuous operationsintegrates 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.

Page 6: Cics Bts Intro

6

Evolutionary within the CICS environment

� Extend the CICS APIFamiliar to application developersServicability 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.

Page 7: Cics Bts Intro

7

CICS transactions vs Business Transactions

� CICS TransactionThe 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 TransactionImplements 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

Page 8: Cics Bts Intro

8

Business Transactions

� Today's CICS applications are business transactionsEach 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

Page 9: Cics Bts Intro

9

What BTS provides

� A business application modelSignificant extensions to the CICS API

Synchronous and asynchronous processing

Event-driven control

� A framework for control logicEncourages the production of reusable business logic

� A robust, scalable environmentExtends the ACID transaction semantics

Sysplex enabled

Workload balancing

Page 10: Cics Bts Intro

10

New Objects

• Application Objects• Process• Activity• Container• Event• Timer

• System Programmer Objects• Process type• Repository Files• Local Request Queue

Page 11: Cics Bts Intro

11

CICS BTS application concepts –processes and activities

Process

Activity

Activation(transaction)

� ProcessEnd to end business update

� Activitiesreusable business

functions

ProcessAn instance of a process type

e.g. holiday booking for Fred Bloggs Summer 2006

Has a unique name, to be determined by the applicatione.g. booking reference number

Made up of activities

ActivityEncapsulates part of a processA sequence of one or more activations

where each activation is a CICS transactionMay execute synchronously or asynchronouslyImplements either:

a business function (business activity)control logic (control activity) (perhaps both)

Activities are :

Page 12: Cics Bts Intro

12

CICS BTS application concepts - containers

Containers

� ProcessEnd to end business update

� Activitiesreusable business

functions� Containers

stores for applicationcontrol data andbusiness functionparameters

An Activity is made up of...definitional attributes

Tranid, Program, Userid, Completion Event Nameassociated activity containers, eventsreferences to children

A Process is made up of...reference to the root activityassociated process containers

Stored as a record (or records) in VSAM KSDSs – Repository Filesaccessed on-line via CICS File Controlreadable via off-line utility program

ContainersUsed for passing business data between activities (and activations)Like a named commareas, but:

there may be severalno 32K limit

Page 13: Cics Bts Intro

13

CICS BTS application concepts –events and timers

Timer

Events

� Eventssignals of progress in the

businessfunctions

� Timerssimple event signallers

for the passage of time

EventsA named control signal

used to signal progress in the applicationInitially not-firedEvents 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 eventswith an 'and' or 'or' predicate

TimersA named interval or date/timeHas an associated eventAssociated event fires when timer expires

Time: hours/minutes/secondsDate: year/month/dayofmonth or year/dayofyearInterval: days/hours/minutes/seconds

Page 14: Cics Bts Intro

14

CICS BTS application concepts –transaction scope

� Invoking (activating) Activitiessignals progress

� Synchronous activationLINK – 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

LinkEXEC 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'.

Page 15: Cics Bts Intro

15

CICS BTS application concepts –transaction scope

� Invoking (activating) Activitiessignals progress

� Synchronous activationLINK – same tranRUN – separate tran

new tranid/userid

RUN SYNCThis 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.

Page 16: Cics Bts Intro

16

� Invoking (activating) Activitiessignals progress

� Synchronous activationLINK – same tranRUN – separate tran

new tranid/userid

� Asynchronous activationseparate tranevent signals completionCan run multiple activities in

parallel

CICS BTS application concepts –transaction scope

RUN ASYNCThis 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.

Page 17: Cics Bts Intro

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

ProcessTypesProcess types are the equivalent of the transaction definition for BTS.

Repository FilesYou 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 QueuesEach region has its own LRQ (they must not be shared).

Page 18: Cics Bts Intro

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

Page 19: Cics Bts Intro

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

Page 20: Cics Bts Intro

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.

Page 21: Cics Bts Intro

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 stepby 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.

Page 22: Cics Bts Intro

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!

Page 23: Cics Bts Intro

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

�������������� ���

������

�����������

�����������

������

�����������

���������

�� �����!

"����������

�����!

#��� �����

$�������� ���

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 commits3.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.

Page 24: Cics Bts Intro

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.

Page 25: Cics Bts Intro

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 CreationEXEC CICS DEFINE PROCESS

creates a new process and its root activitySpecifies the attributes of the process

tranid (for activations via RUN)userid ( " " " " )programname

Definitional attributes are fixed for the lifetime of the processstatic relationship to a programsimplifies the dynamics

one program is responsible for handling the eventsOnce defined the activity can have data associated with it by the transaction that creates it.

Activity CreationEXEC CICS DEFINE ACTIVITYDynamically builds the tree of activities in the processSpecifies the attributes of the activity

tranid (for activations via RUN)userid ( " " " " )programname

Definitional attributes are fixed for the lifetime of the activitystatic relationship to a program

Page 26: Cics Bts Intro

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 informIt is up to the process to signal what this means to the outside

worldThe set of updates is completeenterprise data is consistent and shows the results of the

business transactionThe working storage of the process is discardedits purpose has been fulfilledspace freed in the repository file

Page 27: Cics Bts Intro

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-activationCompletion does not mean destruction

Parents can examine completed childrencompletion statusoutput container contents

Parents can 'reuse' child for another piece of workEXEC CICS RESET ACTIVITYprepares activity for work againcan update container contents

activity will get DFHINITIAL event againUseful for 'server' processes

CancelationEXEC CICS CANCEL ACTIVITY (or PROCESS)Will force a premature completion of the activity or processCommitted updates from past activations remain

may need to compensateActivity can then be destroyed or reused

DestructionThe 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

Page 28: Cics Bts Intro

28

Container-based programming

Page 29: Cics Bts Intro

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.

Page 30: Cics Bts Intro

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 thecontainers and invokes thechild 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.

Page 31: Cics Bts Intro

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')

DEFINE ACTIVITY('payroll') PROGRAM('p

! create the employee container on the

EXEC CICS PUT CONTAINER('employee') A

! create the wage container on the payro

EXEC CICS PUT CONTAINER('wage') ACTIV

! invoke the payroll service passing th

EXEC CICS LINK ACTIVITY('payroll')

! examine the status returned on the pay

EXEC CICS GET CONTAINER('status') AC

Program �PAYACT�

EXEC CICS RETRIEVE EVENT

WHEN('....

EXEC CICS LINK PROGRAM(

4. Another application has its own events, but caneasily reuse the business logic byusing 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.

Page 32: Cics Bts Intro

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.

Page 33: Cics Bts Intro

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

Page 34: Cics Bts Intro

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

Page 35: Cics Bts Intro

35

New options in CICS TS v2 and v3.1

Page 36: Cics Bts Intro

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.2PTF for APAR PQ76073

� Performance optimization for simple container-based applications

� Usability for GET CONTAINER INTO

� New MOVE container command

Page 37: Cics Bts Intro

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

Page 38: Cics Bts Intro

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);

Page 39: Cics Bts Intro

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”);

Page 40: Cics Bts Intro

40

Any Questions?

Page 41: Cics Bts Intro

41

Thank You for your Attention

Please fill out a session evaluation form