Part of Switching from another tool, the hub for every migration page.
« Back to documentation homeIf your mainframe virtual services were built in DevTest (formerly CA LISA) on its IBM MQ transport protocol and its copybook data protocol, the parts that took the work carry over: the copybooks, the knowledge of which program answers which request, the fields you match on and the replies you shaped. Traffic Parrot stands in for the IBM® MQ CICS bridge the same way, decoding the COMMAREA with your copybooks and answering on the reply-to queue, and the CICS over IBM® MQ page describes every piece this page maps to.
The biggest difference is what runs where. Traffic Parrot is one standalone server for your HTTP, JMS, native IBM® MQ, file and CICS bridge virtual services, with every virtual service a set of JSON mapping files you keep in version control and edit in a web user interface or with a text editor. It works at the queue, in place of the bridge, so there is no agent to install in the CICS region and no LPAR-side component to operate, and it is licensed by concurrent (floating) instances.
| In DevTest | In Traffic Parrot |
|---|---|
| A virtual service model (VSM) with its virtual service image (VSI), the recorded or authored request and response pairs the service answers from. | A set of mapping files under ibm-mq-mappings, each a request matcher paired with a response, grouped into scenarios; recorded, imported or written by hand, and edited in the mapping editor or in version control. |
| The IBM MQ transport protocol: the queue manager, the request and reply queues, and how a reply is correlated to its request. | A native IBM® MQ connection in ibm-mq-connections.json and a replay session on the bridge request queue. A bridge reply goes to the request's reply-to queue with its correlation id set to the request's message id, as the bridge itself does (Replying as the bridge). |
| The copybook data protocol: the folder of copybook file definitions and the map that picks a definition for each request. | The copybooks directory and its programs.json, which names each program's request and reply copybook (Copybooks). The request's program name picks the copybook, so no mapping from payload to definition is written. |
| The data protocol's code page for the EBCDIC payload. | codePage in the program's entry, IBM037 unless set. |
| Separate request-side and response-side copybook definitions. | requestCopybook and replyCopybook, the same file when the program uses one layout both ways. |
| Request arguments parsed from the copybook fields, and the match style of each (exact, pattern, range) in the VSI. | The JSON view of the request: the program name, every decoded field, the MQMD user and the MQCIH fields. Match them with matchesCicsField (equalTo, matches, greaterThan and the other comparisons) or with any JSON matcher, combined with and, or and not. |
| Response payloads that reference request arguments through property expressions, and magic strings and dates. | Response templating with the cicsField helper for request fields and the other helpers for dates, random values, arithmetic and lookups, inside the reply's JSON. |
| The reply's completion and abend information. | The MQCIH part of the reply: ReturnCode, CompCode, Reason and AbendCode. |
| Think time on a transaction. | A fixed delay on the response. |
| Recording a CICS program through the in-region agent, or recording the MQ traffic with the transport protocol. | A bridge conversation is not recorded. The mapping is written from the program's copybook fields, starting from the request view the log prints, and nothing is installed in the CICS region. |
| A payload no copybook describes, such as an acknowledgement, bypasses copybook processing (lisa.vse.copybook.unknown.passthrough). | A program with no copybook is still matched, on its raw bytes; a request no mapping matches is listed on the IBM® MQ Requests page with the nearest mappings and the field each missed on, so the gap is visible. |
Where a DevTest service would carry the program's copybook in its file definition folder, a request argument on the account number and a response payload with the balance, the same transaction in Traffic Parrot is the program's two copybooks, one index entry and one mapping file:
{
"ACCTBAL": {
"requestCopybook": "ACCTBAL-REQ.cpy",
"replyCopybook": "ACCTBAL-RPY.cpy"
}
}{
"request": {
"destination": { "name": "CICS.BRIDGE.REQUEST", "type": "QUEUE" },
"bodyMatcher": {
"and": [
{ "matchesCicsField": { "field": "ProgramName", "equalTo": "ACCTBAL" } },
{ "matchesCicsField": { "field": "COMMAREA.ACCOUNT-NO", "matches": "[0-9]{10}" } }
]
}
},
"response": {
"destination": { "name": "CICS.BRIDGE.REPLY", "type": "QUEUE" },
"text": "{\"MQCIH\": {\"ReturnCode\": 0, \"CompCode\": 0, \"Reason\": 0, \"AbendCode\": \"\"}, \"COMMAREA\": {\"ACCOUNT-NO\": \"{{cicsField request.body 'COMMAREA.ACCOUNT-NO'}}\", \"BALANCE\": 1500.25, \"STATUS-CODE\": \"OK\", \"RESERVED\": 0}}"
}
}The walkthrough on the IBM® MQ developer container runs exactly this transaction end to end, with the copybooks and a client that puts the request, so it is the quickest way to see the shape your migrated services will take.