500 likes | 664 Views
No Integration Without Tiers. Brock Shaw Torridon Associates. Objective. To look at the opportunities for distributed application integration using IDMS. Consider the alternative strategies available and where these should be used.
E N D
No Integration Without Tiers Brock Shaw Torridon Associates
Objective • To look at the opportunities for distributed application integration using IDMS. • Consider the alternative strategies available and where these should be used. • Examine the three most common protocols from the designer and the programmers perspective.
Topics • What is Integration • What are the technology options • Issues of integration • SQL Call interfaces (ODBC/JDBC) • Message Queue Processing (MQ) • Program to Program interfaces (TCP/IP) • Summary
No Integration without Tiers Client Server Mainframe Midrange
Types of Integration Client Server Mainframe Midrange
SQL Level (Client) Client Server ODBC Mainframe Midrange
SQL Level (Server) Client Server Internet ODBC Mainframe Midrange
Transaction Streams Client Server Posting Transactions AppA AppB Mainframe Midrange
Program to Program Client Server Send & Receive PrgA PrgB Mainframe Midrange
Program to Program Client Server PrgA PrgB Mainframe Midrange
Program to Program Client Server PrgA PrgB Mainframe Midrange
The Integrated IT World Client Server Mainframe Midrange
The Technology Available • ODBC • JDBC • MQ Series • LU6.2 • TCP/IP • SNA • VTAM
ODBC/JDBC • “Open” protocol for real-time DB access • ODBC built as general SQL access tool • JDBC equivalent for Java • Windows or J2EE support • The Calling Program issues an SQL request • Request is linked to a “Data Source” • Response from request as normal SQL • Synchronous
MQ Series • A Message • A Message Queue (Named Entity) • Initiating task “Pushes” message on queue • MQ Software handles all delivery issues • Receiving task “Pops” message from queue • Asynchronous (usually)
TCP/IP • Compare APPI and LU6.2 • TCP/IP and sockets are simpler • Initiating task connects and sends • Receiving task confirms and receives • Message is internally free-format • Receiver unrestricted in message handling • Synchronous or Asynchronous
Issues for Design • Synchronicity • Real-time vs Pseudo-converse • Processing latency • Recoverability • Coordinating Commits • Process efficiency
***Design Case 1***SQL Processing • Program seeks to have direct access to a DB through an SQL command. • Single record processing • Multi-record processing • Efficiency requires maximising each call • What is the call really accessing
SQL Request Architecture • All calls are based on Dynamic SQL
Non-SQL IDMS using SQL Define SQL version of the network schema Take a non-SQL record e.g. CUSTOMER Create SQL Select CREATE SCH CREATE SCHEMA sqlname FOR NONSQL SCHEMA disctnam2.schmname; SELECT * FROM customer WHERE customer_id = “ABC Corp”;
Maximising SQL Power • Design access for probable need • Minimise number of calls for a process • Make access efficient for non-SQL • Normal database efficiency issues • Avoid non-SQL by going Network
Table Procedures and QuickBridge • Define a Table Procedure • Receiving Program Parameter List CREATE TABLE PROCEDURE schmname.table_name ( <normal table element definitions> ); IDENTIFICATION Division . . . PROCEDURE DIVISION USING <same list of element definitions> . . . .
Table Procedure Logic SQL Request QuickBridge template (USING parameter list) BIND RUN-UNIT . . . OBTAIN … . . . FINISH Virtual Table
IDMS Server Architecture Data Source
Designing Transactions • Minimise SQL calls • Preload data where possible • Minimise setup times • Make Table Procedures to handle DML • Ensure SQL compatibility of the network schema
Programming Concerns • Each environment has a protocol to package an SQL call for the ODBC processor. • Call, class method or graphical • Simple SQL handled within IDMS • Table procedure template (QuickBridge) • Error response of a Table Procedure must match that of a real SQL call
***Design Case 2*** Transaction Streams • This is like feeding a batch process • One message at a time • Where is it likely to be found? • Not time critical (i.e. synchronous) • Pushing a message onto a queue • Popping a message off a queue • Asynchronicity
MQ Architecture App A Message Local Queue Message Message Message Message Message Message MQ Routing Information Message Message Message Remote Queue Message Message Message Message App B Message
MQ Calls The calls in the MQI can usefully be grouped as follows: | MQCONN, MQCONNX, and MQDISC | Use these calls to connect a program to (with or without | options), and disconnect a program from, a queue manager. Writers of CICS for MVS/ESA programs or OS/400 programs do not need to use these calls. However, you can use them if you want your application to be portable to other platforms. MQOPEN and MQCLOSE Use these calls to open and close an object, such as a queue. MQPUT and MQPUT1 Use these calls to put a message on a queue. MQGET Use this call to browse messages on a queue, or to remove messages from a queue. MQINQ Use this call to inquire about the attributes of an object. MQSET Use this call to set some of the attributes of a queue. You cannot set the attributes of other types of object. | MQBEGIN, MQCMIT, and MQBACK | Use these calls to start and commit a global unit of work (where | coordination is performed by MQSeries) and indicate to the queue | manager that all messages put or retrieved as part of a unit of | work since the last syncpoint are to be backed out. The MQI calls are described fully in the MQSeries Application Programming Reference manual.
Programming MQ MOVE MQMT-REQUEST TO MQMD-MSGTYPE. MOVE MQCI-NONE TO MQMD-CORRELID. MOVE MQMI-NONE TO MQMD-MSGID. MOVE W02-TEMPORARY-Q TO MQMD-REPLYTOQ. MOVE SPACES TO MQMD-REPLYTOQMGR. MOVE 5 TO MQMD-PRIORITY. MOVE MQPER-NOT-PERSISTENT TO MQMD-PERSISTENCE. COMPUTE MQPMO-OPTIONS = MQPMO-NO-SYNCPOINT + MQPMO-DEFAULT-CONTEXT. MOVE LENGTH OF CSQ4BIIM-MSG TO W03-BUFFLEN. * CALL 'MQPUT' USING W03-HCONN W03-HOBJ-INQUIRY MQMD MQPMO W03-BUFFLEN W03-PUT-BUFFER W03-COMPCODE W03-REASON. IF W03-COMPCODE NOT = MQCC-OK
MQ and DC MQ IDMS-DC Prg 1 Prg 2
MQ and DC MQ IDMS-DC DCMQ Handler Prg 2 Prg 1
MQ and UCF/CICS IDMS-UCF MQ CICS CICSMQ Handler
MQ and DC Queues IDMS-DC MQ Batch DC GET QUEUE . . . PUT QUEUE MQPUT DCRUN
Issues of MQ • Audit issues (Did message arrive?) • Commit issues (like 2PC) • MQ has robust error handling • “Somebody Else’s Problem” • Asynchronicity
***Design Case 3*** Program to Program • Two co-operating processes • Really more like peer to peer • Passing data or messages • Using data to trigger secondary processes • Getting feedback on results • Each process operates within its own view • Problem: coordinating recovery
TCP/IP Architecture Linux TCP/IP Socket API Task A Port 1 Task B Port 2 CICS … … IDMS Advantage CA-IDMS region
Functional View Initiator Listener Process A Process B Create socket Bind Listen
Functional View Initiator Listener Process A Process B Create socket Connect Accept Send Receive Receive Send Close Close
Pseudo Conversations Initiator Listener Process A Process B Create socket Connect Accept Send Receive (Setup Listener) Close (Process data)
Pseudo Conversations Listener Initiator Process A Process B Create socket Connect Accept Send Receive Close Close (Process data)
Its Good to Talk • Where application programs talk directly • Functional orientation • Synchronicity • Pseudo-conversations • Interface independent of data structure • Recovery and commit issues
Programming TCP/IP IF ( SOCKET( SOCKET-FUNCTION-WRITE SOCKET-RETCD, SOCKET-ERRNO, SOCKET-RSNCD, SOCKET-LISTENER-SOCKDESC, BUFFER-ARRAY(WK-SUBSCRIPT), WK-LENGTH, RETLEN) NE 0) THEN DO. WRITE TO LOG MESSAGE TEXT = 'TCPADSL1: WRITE ERROR'. CALL TCPERROR. CALL TCPCLOSE. LEAVE ADS. END.
Best Solution Examples? • Windows app wants to check stock level • Web app wants to do a complex update • Updates need to be applied to other DB • Access to “foreign” system required • Load balancing required for back-end • Cooperating processes - different platforms
Choice of Technology • Horses for courses • Define the applications requirements: • Platforms involved • Best platform for a function • Synchronicity requirements • Latency tolerance • Recoverability • Platform synchronisation (like 2PC)
Objectives Revisited • To look at the opportunities for distributed application integration using IDMS. • Consider the alternative strategies available and where these should be used. • Examine the three most common protocols from the designer and the programmers perspective.
Conclusion Client Server IDMS will survive only if it works well in this context! This is our IT World! Mainframe Midrange
Conclusion Client Server If we don’t embrace these changes, the IT world may just look like this. Midrange