Cics Bts Intro
-
Upload
jose-luis-flores -
Category
Documents
-
view
95 -
download
5
Transcript of Cics Bts Intro
1
BTS for Dummies
(and SHARE attendees!)Ian J Mitchell, CICS TS for z/OS
Architect, IBM Hursley
15th 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 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.
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.
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
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
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
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)
� 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 :
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
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
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'.
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.
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.
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).
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 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.
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
�������������� ���
������
�����������
�����������
������
�����������
���������
�� �����!
"����������
�����!
#��� �����
$�������� ���
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.
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 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
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
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
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 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.
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.
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.2PTF 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