1 / 40

IMS 11 Application Programming Model Capabilities

2. . . PSB. DEVICE. PAYROLL. Application program. . DATABASEPCBStatus Code. MASK. . . MASK. TPI/O-ALT PCBStatus Code. . . ADDRESS. . . NAME. . . . . . . . . . . . IMS Device and Data Independence for Clouds . DBD. AIBReturn/Reason Code. . . IMS hybridClouds. 3. Application Interface Block (A

job
Download Presentation

IMS 11 Application Programming Model Capabilities

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


    1. IMS 11 Application Programming Model Capabilities Kenny Blackman kblackm@us.ibm.com IOD 2009 1293 blackman.ppt In an SOA environment IMS has been used as a Service Provider. However, as new services are required your IMS application needs to be a consumer of a Service. This presentation will cover the various techniques that IMS provides for IMS applications to access external services. IOD 2009 1293 blackman.ppt In an SOA environment IMS has been used as a Service Provider. However, as new services are required your IMS application needs to be a consumer of a Service. This presentation will cover the various techniques that IMS provides for IMS applications to access external services.

    2. 2 IMS Device and Data Independence for Clouds A hybrid cloud combines multiple elements of public and private cloud, including any combination of providers and consumers, and may also contain multiple service layersA hybrid cloud combines multiple elements of public and private cloud, including any combination of providers and consumers, and may also contain multiple service layers

    3. 3 Application Interface Block (AIB) An application program can refer to a PCB by a given NAME, not an address (PCBNAME is 8 bytes). For the I/O-PCB, the name is 'IOPCBbbb' For DB-PCB, the name is specified in the PSBGEN: PCBNAME=... parameter on PCB macro LIST=Y|N - Display PCBNAME in PSB listing? The language-independent CEETDLI interface to IMS™ is provided by Language Environment. It is the only IMS interface that supports the advanced error handling capabilities provided by Language Environment. The CEETDLI interface supports the same functionality as the other IMS application interfaces, and it has the following characteristics: The language-independent CEETDLI interface to IMS™ is provided by Language Environment. It is the only IMS interface that supports the advanced error handling capabilities provided by Language Environment. The CEETDLI interface supports the same functionality as the other IMS application interfaces, and it has the following characteristics:

    4. 4 Alternate PCBs To send a message to the logical terminal that sent the input message, the program uses an I/O PCB. IMS puts the name of the logical terminal that sent the message in the I/O PCB when the program receives the message. As a result, the program need not do anything to the I/O PCB before sending the message An alternate PCB is a data communication program communication block (DCPCB) that you define to describe output message destinations other than the terminal that originated the input message. An alternate response PCB lets you send messages when exclusive, response, or conversational mode is in effect Use an alternate response PCB in a conversation when the terminal you are responding to has two components—for example, a printer and a punch—and you want to send the output message to a component that is separate from the component that sent the input message. If the program references an alternate response PCB, the PCB must be defined for the same physical terminal as the logical terminal that sent the input message. You must specify SAMETRM=YES for response alternate PCBs used by conversational programs and programs operating with terminals in response mode. An express PCB is an alternate response PCB that allows your program to transmit the message to the destination terminal earlier than when you use a nonexpress PCB. EXPRESS messages can be sent to the destination terminal even though the program abends or issues a ROLL or ROLB call. For an express PCB, the message is available for transmission to the destination when IMS knows it has the complete message. The message is available when a PURG call is made using that PCB, or when the program requests the next input message. modifiable alternate PCB feature allows for the dynamic modification of the destination name associated with this PCB.To send a message to the logical terminal that sent the input message, the program uses an I/O PCB. IMS puts the name of the logical terminal that sent the message in the I/O PCB when the program receives the message. As a result, the program need not do anything to the I/O PCB before sending the message An alternate PCB is a data communication program communication block (DCPCB) that you define to describe output message destinations other than the terminal that originated the input message. An alternate response PCB lets you send messages when exclusive, response, or conversational mode is in effect Use an alternate response PCB in a conversation when the terminal you are responding to has two components—for example, a printer and a punch—and you want to send the output message to a component that is separate from the component that sent the input message. If the program references an alternate response PCB, the PCB must be defined for the same physical terminal as the logical terminal that sent the input message. You must specify SAMETRM=YES for response alternate PCBs used by conversational programs and programs operating with terminals in response mode. An express PCB is an alternate response PCB that allows your program to transmit the message to the destination terminal earlier than when you use a nonexpress PCB. EXPRESS messages can be sent to the destination terminal even though the program abends or issues a ROLL or ROLB call. For an express PCB, the message is available for transmission to the destination when IMS knows it has the complete message. The message is available when a PURG call is made using that PCB, or when the program requests the next input message. modifiable alternate PCB feature allows for the dynamic modification of the destination name associated with this PCB.

    5. 5 MESSAGE FORMAT SERVICE The 3270 device is a display device, which has been used as a terminal on the IBM Mainframe network since the earliest days. It remains in extensive use, although typically through a PC emulator program these days. The 3270 device is a display device, which has been used as a terminal on the IBM Mainframe network since the earliest days. It remains in extensive use, although typically through a PC emulator program these days.

    6. 6 This page shows an example of a 2-tiered IMS manage request where the IMS appl isrt to altpcb which invokes TRANB/PGM-B. PGM-B can be in the same IMS system or MSC can be used to access PGM-B in another IMS system. However each IMS program is an independent Unit of Work. CRE TRANDESC NAME(TRANB) PGM(PGM-B) This page shows an example of a 2-tiered IMS manage request where the IMS appl isrt to altpcb which invokes TRANB/PGM-B. PGM-B can be in the same IMS system or MSC can be used to access PGM-B in another IMS system. However each IMS program is an independent Unit of Work. CRE TRANDESC NAME(TRANB) PGM(PGM-B)

    7. 7 IMS Java Regions JMP same as MPP + JVM JBP same as non-message driven BMP + JVM

    8. 8 IMS TM MPP - JVM IMS apar to configure MPP to launch a JVM same as JMP. Uses CEEPIPI to call IMS application program This service has the following software dependencies: 1. z/OS 1.9 (HBB7740) or above is required 2. LE (Language Environment) APAR PK99010 is required 3. LE (Language Environment) APAR PM00482 is required if running z/OS 1.11 or above 4. DB2 APAR PK93123 is required if issuing DB2 calls from the Java application in this environment IMS apar to configure MPP to launch a JVM same as JMP. Uses CEEPIPI to call IMS application program This service has the following software dependencies: 1. z/OS 1.9 (HBB7740) or above is required 2. LE (Language Environment) APAR PK99010 is required 3. LE (Language Environment) APAR PM00482 is required if running z/OS 1.11 or above 4. DB2 APAR PK93123 is required if issuing DB2 calls from the Java application in this environment

    9. 9 COBOL calls Java in MPR … IMS Transaction PSB with LANG=ASSEM Scenario Procedural Application Calls COBOL wrapper that calls Java

    10. 10

    11. 11 IMS Connect Discussion objectives: o To inspire more IMS connect utilization, POST would like to know how IMS connect is used by other customers. o They currently use IMS connect with FISC which supports intermember banks' transactions. o They are on V9 and moving to V11 next yearDiscussion objectives: o To inspire more IMS connect utilization, POST would like to know how IMS connect is used by other customers. o They currently use IMS connect with FISC which supports intermember banks' transactions. o They are on V9 and moving to V11 next year

    12. 12 Existing MFS Web Services customers using MFS tooling in WebSphere Studio Application Developer Integration Edition (WSADIE) need to move to the new tooling (RAD / WID / WDz) supporting the latest J2EE Connector (J2C) programming model and the Service Component Architecture (SCA) programming model to continue developing and running MFS Web Services The MFS BPEL support for WebSphere Integration Developer assists integration developers and advanced J2EE developers with business-to-business transformation. This support creates Web services/EJB/JSPs out of existing MFS-based IMS applications and provides support for Service Component Architecture (SCA), Enterprise Metadata Discovery (EMD) 1.1, and BPEL IMS MFS SOA uses IMS TM Resource Adapter that supports IBM Java integrated development environments (IDEs). Existing MFS Web Services customers using MFS tooling in WebSphere Studio Application Developer Integration Edition (WSADIE) need to move to the new tooling (RAD / WID / WDz) supporting the latest J2EE Connector (J2C) programming model and the Service Component Architecture (SCA) programming model to continue developing and running MFS Web Services The MFS BPEL support for WebSphere Integration Developer assists integration developers and advanced J2EE developers with business-to-business transformation. This support creates Web services/EJB/JSPs out of existing MFS-based IMS applications and provides support for Service Component Architecture (SCA), Enterprise Metadata Discovery (EMD) 1.1, and BPEL IMS MFS SOA uses IMS TM Resource Adapter that supports IBM Java integrated development environments (IDEs).

    13. 13 Main Point: The word mashup actually originated in the music industry, where it refers to the process of creating a new song from pieces of existing songs. This same notion of remixing existing content to get something new and interesting can be applied to web applications – where a mashup is really nothing more than a web application that is created from existing data and functions. Mashups are founded on the primary premise of reuse. As a result, they can be built very very quickly – on the order of a few days or weeks. In addition, with some of the mashup tools available today, such as IBM Mashup Center, the development of mashups can be pushed out to users outside of centralized IT. And in that way, mashups can be a way to lower the barrier to application development. Lotus Widget FactoryMain Point: The word mashup actually originated in the music industry, where it refers to the process of creating a new song from pieces of existing songs. This same notion of remixing existing content to get something new and interesting can be applied to web applications – where a mashup is really nothing more than a web application that is created from existing data and functions. Mashups are founded on the primary premise of reuse. As a result, they can be built very very quickly – on the order of a few days or weeks. In addition, with some of the mashup tools available today, such as IBM Mashup Center, the development of mashups can be pushed out to users outside of centralized IT. And in that way, mashups can be a way to lower the barrier to application development. Lotus Widget Factory

    14. 14 IMS Web 2.0 …

    15. 15 External Subsystem Attach Facility (ESAF) For External Subsystems (ESS) products that want to enable access to their data resources from IMS applications ESAF provides for synchronization of external subsystem data resources with IMS data resources IMS is the recovery coordinator and is responsible for directing commit or abort actions on behalf of its application programs External subsystems are participants in the process and commit or abort data updates by IMS applications

    16. 16 This page shows an example of a 2-tiered MQ requests where the request begins with IMSA-PGMA which invokes a MQ-B MQPMO_SYNCPOINT The request is to operate within the normal unit-of-work protocols. The message is not visible outside the unit of work until the unit of work is committed. If the unit of work is backed out, the message is deleted. If neither this option nor MQPMO_NO_SYNCPOINT is specified, the inclusion of the put request in unit-of-work protocols is determined by the environment: On z/OS®, the put request is within a unit of work. In all other environments, the put request is not within a unit of work. Because of these differences, an application that you want to port must not allow this option to default; specify either MQPMO_SYNCPOINT or MQPMO_NO_SYNCPOINT explicitly. Do not specify MQPMO_SYNCPOINT with MQPMO_NO_SYNCPOINT. MQPMO_NO_SYNCPOINT The request is to operate outside the normal unit-of-work protocols. The message is available immediately, and it cannot be deleted by backing out a unit of work. If neither this option nor MQPMO_SYNCPOINT is specified, the inclusion of the put request in unit-of-work protocols is determined by the environment: On z/OS, the put request is within a unit of work. In all other environments, the put request is not within a unit of work. Because of these differences, an application that you want to port must not allow this option to default; specify either MQPMO_SYNCPOINT or MQPMO_NO_SYNCPOINT explicitly. Do not specify MQPMO_NO_SYNCPOINT with MQPMO_SYNCPOINT. MQPMO_ASYNC_RESPONSE The MQPMO_ASYNC_RESPONSE option requests that an MQPUT or MQPUT1 operation is completed without the application waiting for the queue manager to complete the call. Using this option can improve messaging performance, particularly for applications using client bindings. An application can periodically check, using the MQSTAT verb, whether an error has occurred during any previous asynchronous calls. With this option, only the following fields are guaranteed to be completed in the MQMD; ApplIdentityData PutApplType PutApplName ApplOriginData Additionally, if either or both of MQPMO_NEW_MSG_ID or MQPMO_NEW_CORREL_ID are specified as options, the MsgId and CorrelId returned are also completed. (MQPMO_NEW_MSG_ID can be implicitly specified by specifying a blank MsgId field). Only the fields specified above are completed. Other information that would normally be returned in the MQMD or MQPMO structure is undefined. When requesting asynchronous put response for MQPUT or MQPUT1, a CompCode and Reason of MQCC_OK and MQRC_NONE does not necessarily mean that the message was successfully put to a queue. When developing an MQI application that uses asynchronous put response and requires confirmation that messages have been put to a queue you should check both CompCode & Reason codes from the put operations and also use MQSTAT to query asynchronous error information. Although the success or failure of each individual MQPUT or MQPUT1 call may not be returned immediately, the first error that occurred under an asynchronous call can be determined later through a call to MQSTAT. If a persistent message under syncpoint fails to be delivered using asynchronous put response, and you attempt to commit the transaction, the commit fails and the transaction is backed out with a completion code of MQCC_FAILED and a reason of MQRC_BACKED_OUT. The application can make a call to MQSTAT to determine the cause of a previous MQPUT or MQPUT1 failure. At normal syncpoint.... – MQSeries input messages marked with SYNCPOINT, and MARK_SKIP BACKOUT are dequeued – MQSeries input messages marked with NO_SYNCPOINT have already been dequeued – MQSeries output messages marked with SYNCPOINT are sent – MQSeries output messages marked with NO_SYNCPOINT have already been sent – If the IMS application is message driven (BMP or MPP) the MQSeries connection handle is closed for security reasons – Connection security is by userid – Each message can be from a different userid This page shows an example of a 2-tiered MQ requests where the request begins with IMSA-PGMA which invokes a MQ-B MQPMO_SYNCPOINT The request is to operate within the normal unit-of-work protocols. The message is not visible outside the unit of work until the unit of work is committed. If the unit of work is backed out, the message is deleted. If neither this option nor MQPMO_NO_SYNCPOINT is specified, the inclusion of the put request in unit-of-work protocols is determined by the environment: On z/OS®, the put request is within a unit of work. In all other environments, the put request is not within a unit of work. Because of these differences, an application that you want to port must not allow this option to default; specify either MQPMO_SYNCPOINT or MQPMO_NO_SYNCPOINT explicitly. Do not specify MQPMO_SYNCPOINT with MQPMO_NO_SYNCPOINT. MQPMO_NO_SYNCPOINT The request is to operate outside the normal unit-of-work protocols. The message is available immediately, and it cannot be deleted by backing out a unit of work. If neither this option nor MQPMO_SYNCPOINT is specified, the inclusion of the put request in unit-of-work protocols is determined by the environment: On z/OS, the put request is within a unit of work. In all other environments, the put request is not within a unit of work. Because of these differences, an application that you want to port must not allow this option to default; specify either MQPMO_SYNCPOINT or MQPMO_NO_SYNCPOINT explicitly. Do not specify MQPMO_NO_SYNCPOINT with MQPMO_SYNCPOINT. MQPMO_ASYNC_RESPONSE The MQPMO_ASYNC_RESPONSE option requests that an MQPUT or MQPUT1 operation is completed without the application waiting for the queue manager to complete the call. Using this option can improve messaging performance, particularly for applications using client bindings. An application can periodically check, using the MQSTAT verb, whether an error has occurred during any previous asynchronous calls. With this option, only the following fields are guaranteed to be completed in the MQMD; ApplIdentityData PutApplType PutApplName ApplOriginData Additionally, if either or both of MQPMO_NEW_MSG_ID or MQPMO_NEW_CORREL_ID are specified as options, the MsgId and CorrelId returned are also completed. (MQPMO_NEW_MSG_ID can be implicitly specified by specifying a blank MsgId field). Only the fields specified above are completed. Other information that would normally be returned in the MQMD or MQPMO structure is undefined. When requesting asynchronous put response for MQPUT or MQPUT1, a CompCode and Reason of MQCC_OK and MQRC_NONE does not necessarily mean that the message was successfully put to a queue. When developing an MQI application that uses asynchronous put response and requires confirmation that messages have been put to a queue you should check both CompCode & Reason codes from the put operations and also use MQSTAT to query asynchronous error information. Although the success or failure of each individual MQPUT or MQPUT1 call may not be returned immediately, the first error that occurred under an asynchronous call can be determined later through a call to MQSTAT. If a persistent message under syncpoint fails to be delivered using asynchronous put response, and you attempt to commit the transaction, the commit fails and the transaction is backed out with a completion code of MQCC_FAILED and a reason of MQRC_BACKED_OUT. The application can make a call to MQSTAT to determine the cause of a previous MQPUT or MQPUT1 failure. At normal syncpoint.... – MQSeries input messages marked with SYNCPOINT, and MARK_SKIP BACKOUT are dequeued – MQSeries input messages marked with NO_SYNCPOINT have already been dequeued – MQSeries output messages marked with SYNCPOINT are sent – MQSeries output messages marked with NO_SYNCPOINT have already been sent – If the IMS application is message driven (BMP or MPP) the MQSeries connection handle is closed for security reasons – Connection security is by userid – Each message can be from a different userid

    17. 17 This page shows an example of a 2-tiered MQ requests where the request begins with IMSA-PGMA which invokes a MQ-B At normal syncpoint.... – MQSeries input messages marked with SYNCPOINT, and MARK_SKIP BACKOUT are dequeued – MQSeries input messages marked with NO_SYNCPOINT have already been dequeued – MQSeries output messages marked with SYNCPOINT are sent – MQSeries output messages marked with NO_SYNCPOINT have already been sent – If the IMS application is message driven (BMP or MPP) the MQSeries connection handle is closed for security reasons – Connection security is by userid – Each message can be from a different userid Whenever the connection to WebSphere® MQ is restarted, either following a queue manager restart or an IMS™ /START SUBSYS command, IMS initiates the following resynchronization process: IMS presents the list of unit of work (UOW) IDs that it believes are in doubt to the WebSphere MQ IMS adapter one at a time with a resolution parameter of Commit or Backout. The IMS adapter passes the resolution request to WebSphere MQ and reports the result back to IMS. Having processed all the IMS resolution requests, the IMS adapter gets from WebSphere MQ a list of all UOWs that WebSphere MQ still holds in doubt that were initiated by the IMS system. These are reported to the IMS master terminal in message CSQQ008I. Note: While a UOW is in doubt, any associated WebSphere MQ message is locked by WebSphere MQ and is not available to any application. This page shows an example of a 2-tiered MQ requests where the request begins with IMSA-PGMA which invokes a MQ-B At normal syncpoint.... – MQSeries input messages marked with SYNCPOINT, and MARK_SKIP BACKOUT are dequeued – MQSeries input messages marked with NO_SYNCPOINT have already been dequeued – MQSeries output messages marked with SYNCPOINT are sent – MQSeries output messages marked with NO_SYNCPOINT have already been sent – If the IMS application is message driven (BMP or MPP) the MQSeries connection handle is closed for security reasons – Connection security is by userid – Each message can be from a different userid Whenever the connection to WebSphere® MQ is restarted, either following a queue manager restart or an IMS™ /START SUBSYS command, IMS initiates the following resynchronization process: IMS presents the list of unit of work (UOW) IDs that it believes are in doubt to the WebSphere MQ IMS adapter one at a time with a resolution parameter of Commit or Backout. The IMS adapter passes the resolution request to WebSphere MQ and reports the result back to IMS. Having processed all the IMS resolution requests, the IMS adapter gets from WebSphere MQ a list of all UOWs that WebSphere MQ still holds in doubt that were initiated by the IMS system. These are reported to the IMS master terminal in message CSQQ008I. Note: While a UOW is in doubt, any associated WebSphere MQ message is locked by WebSphere MQ and is not available to any application.

    18. 18 This page shows an example of an invoking a stored procedure where the request begins with IMS-Appl which calls the SP which ultimately invokes a web service, DB2 as a web services consumer: DB2 can act as a client for web services, which enables you to be a consumer of web services in your DB2 applications. web services employs Simple Object Access Protocol (SOAP). SOAP is an XML protocol that consists of the following characteristics: An envelope that defines a framework for describing the contents of a message and how to process the message A set of encoding rules for expressing instances of application-defined data types A convention for representing SOAP requests and responses This page shows an example of an invoking a stored procedure where the request begins with IMS-Appl which calls the SP which ultimately invokes a web service, DB2 as a web services consumer: DB2 can act as a client for web services, which enables you to be a consumer of web services in your DB2 applications. web services employs Simple Object Access Protocol (SOAP). SOAP is an XML protocol that consists of the following characteristics: An envelope that defines a framework for describing the contents of a message and how to process the message A set of encoding rules for expressing instances of application-defined data types A convention for representing SOAP requests and responses

    19. 19 The structure of the library changed quite a lot with IMS Version 10. In Version 11 we will improve the content of information deliverables, but the overall library structure will remain largely the same, with the exception to the noted areas above. The structure of the library changed quite a lot with IMS Version 10. In Version 11 we will improve the content of information deliverables, but the overall library structure will remain largely the same, with the exception to the noted areas above.

    20. 20 The structure of the library changed quite a lot with IMS Version 10. In Version 11 we will improve the content of information deliverables, but the overall library structure will remain largely the same, with the exception to the noted areas above. The structure of the library changed quite a lot with IMS Version 10. In Version 11 we will improve the content of information deliverables, but the overall library structure will remain largely the same, with the exception to the noted areas above.

    21. 21

    22. 22 IMS Solutions for Java Development IMS 11 Open Database APIs JDBC 3.0 IBM SDK V5 z/OS CICS,DB2,WebSphere IBM SDK V6 z/OS IMS TM IMS 9,10 Java Drivers JDBC 2.1 IBM SDK V1.3.1 IMS 9 IBM SDK V1.4.2 IMS 9 IBM SDK V5 z/OS IMS 10 The IMS JDBC Driver enables JDBC access to IMS DB from IMS TM JMP/JBP environments, CICS Java application, DB2 Java Stored procedure, and Enterprise Java Beans running on WebSphere distributed and z/OS environments. IMS V9 requires SDK V1.4.2 for JMP and JBP regions, IMS DB Resource Adapter for CICS, DB2 or WAS requires SDK V1.3.1 or higher. IMS V10 requires SDK V5 for JMP and JBP regions, IMS DB Resource Adapter for CICS, DB2 or WAS requires SDK V1.4.2 or higher. The IMS Universal drivers have the following runtime software requirements: Java Development Kit (JDK) 5.0 or later for CICS Transaction Server for z/OS Version 3.1 for DB2 for z/OS Version 9.1 or DB2 UDB for z/OS Version 8 for WebSphere Application Server for z/OS or WebSphere Application Server for distributed platforms, Version 6.1 for JMP and JBP regions require Java Development Kit JDK 6.0 or later The IMS JDBC Driver enables JDBC access to IMS DB from IMS TM JMP/JBP environments, CICS Java application, DB2 Java Stored procedure, and Enterprise Java Beans running on WebSphere distributed and z/OS environments. IMS V9 requires SDK V1.4.2 for JMP and JBP regions, IMS DB Resource Adapter for CICS, DB2 or WAS requires SDK V1.3.1 or higher. IMS V10 requires SDK V5 for JMP and JBP regions, IMS DB Resource Adapter for CICS, DB2 or WAS requires SDK V1.4.2 or higher. The IMS Universal drivers have the following runtime software requirements: Java Development Kit (JDK) 5.0 or later for CICS Transaction Server for z/OS Version 3.1 for DB2 for z/OS Version 9.1 or DB2 UDB for z/OS Version 8 for WebSphere Application Server for z/OS or WebSphere Application Server for distributed platforms, Version 6.1 for JMP and JBP regions require Java Development Kit JDK 6.0 or later

    23. 23 XML DB Highlights - Decomposed data Retrieve - Compose XML document from any existing traditional database Insert - Decompose XML docs back into same DB Same data can be read by existing IMS applications With decomposed document storage, IMS converts the XML data to traditional IMS data types, and as a result, the data can be searched by IMS. With the XML DB enhancements, you can compose XML documents from traditional data in existing IMS databases. You can also receive XML documents, and decompose them and store their data back into existing IMS databases as traditional data. Tooling (the DLIModel utility) provides assistance to define the required metadata mapping between XML documents and IMS databases. This support allows users to write Java applications to compose and receive XML documents in any of the following environments: IMS dependent region (JMP or JBP) WebSphere Application Server for z/OS WebSphere Application Server on a non-z/OS platform DB2 UDB for z/OS stored procedure CICS JCICS region Decomposed XML storage The XML tags are stripped from the XML document and only the data is extracted. The extracted data is converted into traditional IMS field types and inserted into the database. Use this approach in the following scenarios: XML applications and non-XML applications must access the same database Extensive searching of the database is needed A strict XML schema is available With decomposed document storage, IMS converts the XML data to traditional IMS data types, and as a result, the data can be searched by IMS. With the XML DB enhancements, you can compose XML documents from traditional data in existing IMS databases. You can also receive XML documents, and decompose them and store their data back into existing IMS databases as traditional data. Tooling (the DLIModel utility) provides assistance to define the required metadata mapping between XML documents and IMS databases. This support allows users to write Java applications to compose and receive XML documents in any of the following environments: IMS dependent region (JMP or JBP) WebSphere Application Server for z/OS WebSphere Application Server on a non-z/OS platform DB2 UDB for z/OS stored procedure CICS JCICS region Decomposed XML storage The XML tags are stripped from the XML document and only the data is extracted. The extracted data is converted into traditional IMS field types and inserted into the database. Use this approach in the following scenarios: XML applications and non-XML applications must access the same database Extensive searching of the database is needed A strict XML schema is available

    24. 24 XML DB Highlights - Intact Data Insert/Retrieve/Delete new XML documents INTACT in new IMS databases Intact data is not expected to be understood by other IMS applications XML Documents span IMS segments Stored in Unicode Intact XML storage In this case the XML document is stored, with its XML structure and tags intact, in an IMS database designed exclusively for storing intact XML documents. In this case, only Java application programs can access the data in the database. Because the XML document does not have to be regenerated when the data is retrieved from the database, the retrieval of the XML data is typically faster than when it is stored without its XML tagging. Use this approach in the following scenarios: Faster storage and retrieval of XML documents are needed Less searching of the database is required The XML schema requires more flexibility Intact XML storage requires a new IMS database or an extension of an existing database because the XML document must be stored in segments and fields that are specifically tailored for storing intact XML. To store all or part of an XML document intact in an IMS database, the database must define a base segment, which contains the root element of the intact XML sub-tree. The rest of the intact XML sub-tree is stored in overflow segments, which are child segments of the base segment. Side Segments for Secondary Indexing IMS cannot search intact XML documents for specific elements within the document. However, you can create a side segment that contains specific XML element data. IMS stores the XML document intact, and also decomposes a specific piece of XML data into a standard IMS segment. This segment can then be searched with a secondary index. This support allows users to write Java applications in any of the following environments: IMS dependent region (JMP or JBP) WebSphere Application Server for z/OS WebSphere Application Server on a non-z/OS platform DB2 UDB for z/OS stored procedure CICS JCICS region Intact XML storage In this case the XML document is stored, with its XML structure and tags intact, in an IMS database designed exclusively for storing intact XML documents. In this case, only Java application programs can access the data in the database. Because the XML document does not have to be regenerated when the data is retrieved from the database, the retrieval of the XML data is typically faster than when it is stored without its XML tagging. Use this approach in the following scenarios: Faster storage and retrieval of XML documents are needed Less searching of the database is required The XML schema requires more flexibility Intact XML storage requires a new IMS database or an extension of an existing database because the XML document must be stored in segments and fields that are specifically tailored for storing intact XML. To store all or part of an XML document intact in an IMS database, the database must define a base segment, which contains the root element of the intact XML sub-tree. The rest of the intact XML sub-tree is stored in overflow segments, which are child segments of the base segment. Side Segments for Secondary Indexing IMS cannot search intact XML documents for specific elements within the document. However, you can create a side segment that contains specific XML element data. IMS stores the XML document intact, and also decomposes a specific piece of XML data into a standard IMS segment. This segment can then be searched with a secondary index. This support allows users to write Java applications in any of the following environments: IMS dependent region (JMP or JBP) WebSphere Application Server for z/OS WebSphere Application Server on a non-z/OS platform DB2 UDB for z/OS stored procedure CICS JCICS region

    25. 25 Universal Drivers

    26. 26 Web 2.0 With IMS 11, access to databases has been opened up through enhancements to IMS Connect and the new Open Database Manager (ODBM) support. The IBM Mashup Center V2.0 supports enterprise database plugins including the IMS universal drivers which support access to IMS database resources as database feeds. With IMS 11, access to databases has been opened up through enhancements to IMS Connect and the new Open Database Manager (ODBM) support. The IBM Mashup Center V2.0 supports enterprise database plugins including the IMS universal drivers which support access to IMS database resources as database feeds.

    27. Finding answers to “Why?” is usually automated with pieces of BI. The major issue with BI in organizations is that the tools have grown up regionally and functionally so it’s a patchwork of different applications and tools. The result is that, from a business user perspective, they end up with different interfaces, different time periods and gaps in the information so there is a lack of confidence in the numbers. From an IT perspective, there are huge costs to maintaining a host of different tools. It costs money, it costs time, it takes lots of people, there are inefficiencies. There are no sharing of resources, report objects and you need a help desk for every one. Only Cognos 8 Reporting delivers customers … Author once, consume anywhere Breadth of report coverage Report life cycle Open data access Finding answers to “Why?” is usually automated with pieces of BI. The major issue with BI in organizations is that the tools have grown up regionally and functionally so it’s a patchwork of different applications and tools. The result is that, from a business user perspective, they end up with different interfaces, different time periods and gaps in the information so there is a lack of confidence in the numbers. From an IT perspective, there are huge costs to maintaining a host of different tools. It costs money, it costs time, it takes lots of people, there are inefficiencies. There are no sharing of resources, report objects and you need a help desk for every one. Only Cognos 8 Reporting delivers customers … Author once, consume anywhere Breadth of report coverage Report life cycle Open data access

    28. 28

    29. 29

    30. 30 IMS Enterprise Suite Explorer The IMS Explorer provides support for the application development cycle GUI view of IMS PSB and DBD application resources Contextual help information to reduce the development effort Assistance for Unit Testing Ability to access IMS data via SQL Focus is on improving IMS application development Simplify common IMS application development tasks

    31. 31

    32. 32

    33. 33

    34. 34

    35. 35

    36. 36

    37. 37

    38. 38

    39. 39

    40. 40 Cloud Break

    41. 41

More Related