IMS OTMA Basics

®

Click to add text

IMS OTMA Basics

[email protected]

End to end for an OTMA Transaction

OTMA

OTMA

IMS Control Region

XCF

OTMA - What is it?Component of IMS

Provides standard access into IMS from any MVS client Uses MVS Cross-System Coupling Facility (XCF) interface

Allows high performance cross-address space communications

CommunicationsAnalyzer (DDMs)APPCLU Manager

OTMA

VTAM APPC/MVS

OTMAClient

XCF Concept

OTMA - What is it? ...Basic terminology

The IMS support for XCF is called OTMAIMS functions as a SERVER

An MVS address space that issues XCF calls to IMS is called an OTMA Client Clients can access IMS transactions and commands User-written or vendor-providedMust be authorized - MVS XCF services

XCF calls - OTMA

XCFCalls

OtherCommunicationsAPI XCF

Group

APPC LUM

DFSICIO0 - DDMs, etc.

OTMA Client IMS

Configuration to IMS/TM via OTMA

HWS (ID=ICONN01,RACF=N,) TCPIP (ECB=Y,HOSTNAME=TCPIP,PORTID=(3336),EXIT=(HWSSMPL1,HWSIMSO1)) DATASTORE(ID=IMSA,MEMBER=ICA,GROUP=IMSXCF,TMEMBER=IMSV10)DATASTORE(ID=IMSB,MEMBER=ICA1,GROUP=IMSXCF,TMEMBER=IMSPROD3)

XCF Group Name IMS systems

ICONN01

IMS Connect

OTMA=YGRNAME=IMSXCFOTMANM=IIMSV10

TCPIP Network

IMSXCFICA

IMSV10Application specifies:Host DNS name, IMS Connect Port (e.g. 3336)and Datastore ID (e.g. IMSA or IMSB)

TCP/IP

Host DNSname

3336

OTMA=YGRNAME=IMSXCFOTMANM=IMSPROD3

IMSPROD3ICA1

OTMA Clients

OTMA client = OTMA member = OTMA Tmember

Tmember is mainly used in IMS command for OTMA

WebSpherewith

TM ResourceAdapter

DB2DSNAIMS

WebSphere optimized local

adapter

WebSphere MQ

IMS Connect

Object ServiceBroker by Tibco

DB

Shadowby Neon

Tuexdoby Oracle

OTMA

IMSTM/DB

DataPower

IMSSoap Gateway

OTMA Protocols

Info about Tran-Server token- LTERM/MOD- Sync Flag...

Message Control Information

State Data Security Data User Data Application Data

PREFIX

Info about message- Type of Message

e.g., TXN, OTMA CMD, Response, etc.

- TPIPE name...

Security info- Security level- Userid, Profile

Variable lengthup to 1024- Optional user data

LLZZTrancode DataLLZZData

OTMA Message ProtocolAll messages sent between IMS and the OTMA Client

Have a pre-defined OTMA Message PrefixAllows a protocol for IMS and the OTMA client to interpret the data

TPIPEA

TPIPEA

Client 1prefix + msg for TRANA using TPIPEA

Client 2prefix + msg for TRANA using TPIPEA

TRANA

IMS

Transaction Pipes (TPIPEs)OTMA TPIPE

IMS construct (control block) Allows IMS to associate messages with a specific client

OTMA TPIPEs are not predefined Different clients could use same TPIPE name (treated as unique instances) TPIPE structure is created dynamically

IMS Application cannot see the OTMA prefix

GU, iopcb

ISRT,iopcb

GU, iopcb

ISRT, iopcb

TPIPEA

Client 1

prefix + msg for TRANA using TPIPEA

prefix + msg for TRANZusing TPIPEA and LTERMB MODB

GU, iopcb

ISRT,iopcb

TRANA

GU, iopcb

ISRT, iopcb

IMSIOPCB mask

TPIPEA

MODBLTERMB

IOPCB mask

Transaction Pipes (TPIPEs)...For IMS Applications, TPIPE LTERM

Shows by default as LTERM in the IOPCB For IMS Connect

CLIENT ID if commit mode is 0PORT ID if the commit mode is 1

State Data section of the MSG Prefix may provide IOPCB overrides LTERM name MOD name

Commit Processing

Commit Modes Flag in the State Data section of the Prefix Commit-Then-Send (Commit Mode 0)

Traditional IMS flowIMS processes the transaction, commits the data, sends the responseMessages are enqueued prior to being sent

Send-Then-Commit (Commit Mode 1) IMS processes the transaction, sends the response, and if successful, commits the dataReply messages do not go via the IMS message queues

Commit Processing Synchronization Level

Flag in the State Data section of the Prefix NONE

IMS application does not request an ACK message when sending output to a client IMS application issues the commit after message is sent

CONFIRMIMS requests ACK message prior to commitIMS sends transaction output with the Response Requested flag set This is always true for CM0 output message

SYNCPOINTThis message is part of a protected conversationThe resources updated under this conversation use the two-phase commit protocol

CLIENT IMS

Send transaction input

ACK

Transaction inserted to SMB

ACK

Ouput enqueued to TPIPE

Output sent with response requested

Output dequeued

MPP

GU, IOPCB...ISRT,IOPCB...Synchpoint StartsSynchpoint Completes

Commit-Then-Send Flow (CM 0)

CLIENT IMS


Ouput Sent (No response requested)Commit Confirmed sent(Synchpoint has completed)

MPP

GU, IOPCB.ISRT,IOPCB...Synchpoint Starts

Synchpoint Completes

CLIENT IMS


Ouput Sent Response requested

Commit Confirmed sent(Synchpoint has completed)

MPP

GU, IOPCB.ISRT,IOPCB...Synchpoint Starts

Synchpoint Completes



ACK

Send-Then-Commit Flow (CM1)

Sync Level of NONE

Sync Level of CONFIRM

Send-then-commit Commit-then-send(CM1) (CM0)

No outputACK is needed

OutputACK is needed

Use RRSto

commit/backout

Sequence# is used for input/

output

Sequence# is not used for

input/output

OTMA Resync.

OTMAProtocol

Acknowledgement (ACK) for CM0 output is ALWAYS needed.

SyncLevel

For Inbound Message to IMS:

SyncLevel is Confirm

None Confirm SyncPt

Alternate PCB Output OTMA-submitted transactions

Alternate PCB output destined for another transaction (program-program switch) will always be sent to that transaction

Otherwise by default the message is sent back to the originating OTMA client To allow messages to go to other destinations, IF no destination descriptor entry is

selected, then two OTMA user exits are used to define destination: Prerouting Exit (DFSYPRX0)

− Selects destination client (OTMA client or IMS TM)Destination Resolution Exit (DFSYDRU0)

− Determine final destination for the output

Non-OTMA-submitted transactions (e.g., from IMS Lterms, APPC) Alternate PCB output can be sent to an OTMA client only if the OTMA Exits or

destination descriptors have been coded

Alternate PCB output for OTMA Clients Can be rejected by OTMA clients that do not support unsolicited output

OTMA Implementation No IMS System Generation specification

DFSPBxxx OTMA - Related Parameters GRNAME=

Specifies a one- to eight-character name of the XCF group for IMS Open Transaction Manager Access (OTMA).

The member name IMS uses when joining the XCF group comes from the USERVAR specification or defaults to the IMS APPLID specification.

OTMA=Y|N – activate OTMA during IMS initialization OTMAASY= Y!N

Specifies send_then_commit pgm_to_pgm msg-switch asynch schedule OTMAMD= Y!N

Specifies whether the member override function of the OTMA Prerouting Exit routine (DFSYPRX0) is enabled for a transaction initiated from an OTMA client.

OTMANM= Specifies the member name IMS uses when joining the XCF group for non-RSR or

non-XRF systems. OTMASE=

Specifies the type of OTMA RACF security. OTMASP= Y!N

Specifies whether a non-synchronous Tpipe or a synchronous Tpipe will be created to deliver the OTMA output.

Valid values are Y(create a synchronous Tpipe) or N(create a non-synchronous Tpipe).

OTMA Descriptors

Two types of OTMA descriptors defined in DFSYDTx proclib member

Type M descriptor entry Called OTMA Client Descriptor entry Each OTMA client or member or tmember can have 1 entry It can be used to optionally define the OTMA DRU exit name, flood control values,

ACK timeout value, transaction expiration dump attribute, and Tpipe parallelism. DFSYOTMA is a special entry to specify the global values for all the clients.

Type D descriptor entry Called OTMA destination descriptor entry This entry can be defined to route the OTMA ALTPCB output message so that the

destination info can be specified. For example, which IMS Connect or MQSeries is going to get the output. This is to avoid coding DFSYDRU0/DFSYPRX0 user exits.

This entry can be defined to route ICAL callout message This entry can be defined to perform synchronus program switches.

OTMA Security

OTMA security settings: (controlled by OTMASE (in DFSPBxxx member or by /SECURE OTMA command) NONE

JOIN

FULL

CHECK

PROFILE

IMS OTMA performs security checking in 3 places: OTMA Client Bid security – for connection

OTMA Message security – for transactions and commands

OTMA Resume Tpipe security – for async messages and ICAL messages for IMS Connect

24

OTMA ACEE Caching

OTMA has cache of ACEEs (common for all TMEMBERs)• OTMASE = CHECK | FULL | PROFILE not NONE• OTMA initially allocates storage for 10,000 userid entries at IMS start up

provides AGING to automatically refresh userid • between 300 – 999,999 seconds

• default 999,999 (11.5 days) • can set on ICON DATASTORE OAAV parameter for client-bid

manually refresh ACEE(s) by command• all userids

/SEC OTMA REFRESH • specific userid

/SEC OTMA REFRESH USER userid

Requirement: add RACF Event Notification (ENF) support (supported in V14)• listen for RACF changes (ENF 71)• automatically refresh cache if userid found

Example: a cached userid would still be valid until aged even when administrator revokes userid – With ENF, it will invalidate it and new transactions/commands would fail

OTMA Debugging Tips

Use the IMS TPIPE trace for debugging

/TRA SET ON TMEMBER xxx ---- for tmember and all the tpipes traced

/TRA SET ON TMEMBER xxxx TPIPE yyyy

Produces x’6701’ IMS log recordsFormat with DFSERA10 and DFSERA30

The OTMA headers start at offset x’50’ in the MSG PREF section

They are truncated

Message text is in the I/O BUFF section Only the first segment of a multi-segment message is traced

/TRA SET ON TABLE OTMT is an internal OTMA trace It is for IBM L2/L3/Development

IMS OTMA Basics

Technology

Transcript of IMS OTMA Basics