Author: Robert Sample
Posted: Fri Mar 10, 2017 3:55 am (GMT 5.5)
For CICS 4.1, I found:
and
and
So according to what you've said, you set up LE support for PL/I and you activated z/OS support for Unicode, along with installing the conversion image(s) you need -- this may not be needed depending upon which release of z/OS you're running. And you've installed the PIPELINE resource definition for your Web service. And if you used the CICS Web services assistant, you've added the PERFORM PIPELINE SCAN to your code. And you've defined your web service binding file with the WSBIND attribute of the WEBSERVICE resource. And you've used DFHWS2LS or DFHLS2WS with your WSDL. Remember, all this has to be completed before you can use CICS web services -- the link you quoted appears to assume that all this has already been done.
_________________
TANSTAAFL
The first rule of code reuse is that the code needs to be worth re-using.
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Donald Knuth
Posted: Fri Mar 10, 2017 3:55 am (GMT 5.5)
For CICS 4.1, I found:
| Quote: |
| Configuring your CICS system for Web services Before you can use Web services, your CICS® system must be correctly configured. Procedure Ensure that you have installed Language Environment® support for PL/I. Activate z/OS® Support for Unicode. You must enable the z/OS conversion services and install a conversion image that specifies the data conversions that you want CICS to perform between SOAP messages and an application program. For more information, see z/OS Support for Unicode: Using Conversion Services. CICS resources for Web services These CICS resources support Web services in CICS. Configuring CICS to use the WebSphere MQ transport To use the WebSphere® MQ transport with Web services in CICS, you must configure your CICS region accordingly. |
| Quote: |
| CICS resources for Web services These CICS® resources support Web services in CICS. PIPELINE A PIPELINE resource definition is required for every Web service. It provides information about the message handler programs that act on a service request and on the response. Typically, a single PIPELINE definition defines an infrastructure that can be used by many applications. The information about the message handlers is supplied indirectly: the PIPELINE specifies the name of a z/OS UNIX file thatcontains an XML description of the handlers and their configuration. A PIPELINE resource that is created for a service requester cannot be used for a service provider, and vice versa. The two sorts of PIPELINE are distinguished by the contents of the pipeline configuration file that is specified in the CONFIGFILE attribute: for a service provider, the top-level element is <provider_pipeline>; for a service requester, it is <requester_pipeline>. WEBSERVICE A WEBSERVICE resource definition is required only when the mapping between application data structure and SOAP messages has been generated using the CICS Web services assistant. It defines aspects of the run time environment for a CICS application program deployed in a Web services setting. Although CICS provides the usual resource definition mechanisms for WEBSERVICE resources, they are typically created automatically from a Web service binding file when the pickup directory for the PIPELINE is scanned. This can occur when the PIPELINE resource is installed or as a result of a PERFORM PIPELINE SCAN command. The attributes applied to the WEBSERVICE resource in this case come from a Web services binding file, which is created by the Web services assistant; information in the binding file comes from the Web service description, or is supplied as a parameter of the Web services assistant. A WEBSERVICE resource that is created for a service requester cannot be used for a service provider, and vice versa. The two sorts of WEBSERVICE are distinguished by the PROGRAM attribute: for a service provider, the attribute must be specified; for a service requester, it must be omitted. URIMAP A URIMAP definition is required in a service provider when it contains information that maps the URI of an inbound Web service request to the other resources (such as the PIPELINE) that will service the request. A URIMAP definition is also required if you are using HTTP basic authentication, because the URIMAP specifies that the service requester user ID information is passed in an HTTP authorization header to the service provider. For more information about HTTP basic authentication, see HTTP basic authentication. Although CICS provides the usual resource definition mechanisms, for service providers deployed using the CICS Web services assistant, the URIMAP resources are typically created automatically from a Web service binding file when the pickup directory for the PIPELINE is scanned. This scan occurs when the PIPELINE resource is installed or as a result of a PERFORM PIPELINE SCAN command. The attributes applied to the URIMAP resource in this case come from a Web services binding file, which is created by the Web services assistant; information in the binding file comes from the Web service description or is supplied as a parameter of the Web services assistant. TCPIPSERVICE A TCPIPSERVICE definition is required in a service provider that uses the HTTP transport. It contains information about the port on which inbound requests are received. The resources that are required to support a particular application program depend on the following criteria: Whether the application program is a service provider or a service requester. Whether the application is deployed with the CICS Web services assistant. Service requester or provider CICS Web services assistant used PIPELINE required WEBSERVICE required URIMAP required TCPIPSERVICE required Provider Yes Yes Yes (but see note 1) Yes (but see note 1) See note 2 No Yes No Yes See note 2 Requester Yes Yes Yes No No No Yes No No No Notes When the CICS Web service assistant is used to deploy an application program, the WEBSERVICE and URIMAP resources can be created automatically when the pickup directory of the PIPELINE is scanned. This scan occurs when the PIPELINE resource is installed or as a result of a PERFORM PIPELINE SCAN command. A TCPIPSERVICE resource is required when the HTTP transport is used. When the WebSphere® MQ transport is used, a TCPIPSERVICE resource is not required. Typically, when you deploy many Web services applications in a CICS system, you have more than one of each type of resource. In this case, you can share some resources between applications. Table 1. Resources available for each file and resourceFile or resource Number and type of resource Pipeline configuration file More than one PIPELINE resource that refers to the file. PIPELINE resource More than one URIMAP resource that refers to the PIPELINE. More than one WEBSERVICE resource that refers to the PIPELINE. More than one Web service binding file in the pickup directory of the PIPELINE . Web service binding file Just one URIMAP resource that is automatically generated from the binding file. But you can define further URIMAPs using RDO. Just one WEBSERVICE resource that is automatically generated from the binding file. But you can define further WEBSERVICEs using RDO. WEBSERVICE More than one URIMAP resource. If the WEBSERVICE resource is automatically generated from the binding file, there is just one corresponding URIMAP resource. But you can define further URIMAP resources using RDO. URIMAP Just one TCPIPSERVICE when it is explicitly named in the URIMAP resource. TCPIPSERVICE Many URIMAP resources. |
| Quote: |
| Configuring CICS to use the WebSphere MQ transport To use the WebSphere® MQ transport with Web services in CICS®, you must configure your CICS region accordingly. Procedure Include the following WebSphere MQ library in the STEPLIB concatenation in your CICS procedure. Include the library after the CICS libraries to ensure that the correct code is used. thlqual.SCSQAUTH where thlqual is the high-level qualifier for the WebSphere MQ libraries. Include the following WebSphere MQ libraries in the DFHRPL concatenation in your CICS procedure. Again, include the libraries after the CICS libraries to ensure that the correct code is used. thlqual.SCSQCICS thlqual.SCSQLOAD thlqual.SCSQAUTH where thlqual is the high-level qualifier for the WebSphere MQ libraries. If you are using the CICS-WebSphere MQ API-crossing exit (CSQCAPX), also add the name of the library that contains the load module for the program. The SCSQCICS library is required only if you want to run WebSphere MQ supplied samples. Otherwise it can be removed from the CICS procedure. Install an MQCONN resource definition for the CICS region. The MQCONN resource definition specifies the attributes of the connection between CICS and WebSphere MQ, including the name of the default WebSphere MQ queue manager or queue-sharing group for the connection. For information on how to do this, see Setting up an MQCONN resource definition. Specify the CICS system initialization parameter MQCONN=YES to start the CICS-WebSphere MQ connection automatically at CICS initialization. An MQCONN resource definition must be installed before CICS can start the connection to WebSphere MQ. When you start the connection automatically at CICS initialization, for an initial or cold start, the MQCONN resource definition must be present in one of the groups named in the list or lists named by the GRPLIST system initialization parameter. For a warm or emergency start of CICS, the MQCONN resource definition must have been installed by the end of the previous CICS run. If you are using the CICS-WebSphere MQ adapter in a CICS system that has interregion communication (IRC) to remote CICS systems, ensure that the IRC facility is OPEN before you start the adapter, by specifying the CICS system initialization parameter IRCSTRT=YES. The IRC facility must be OPEN if the IRC access method is defined as cross-memory; that is, ACCESSMETHOD(XM). Ensure that the coded character set identifiers (CCSIDs) used by your queue manager and by CICS, and the UTF-8 and UTF-16 code pages are configured to z/OS® conversion services. The CICS code page is specified in the LOCALCCSID system initialization parameter. Update your CICS CSD as follows: If you do not share your CSD with earlier releases of CICS, remove the groups CSQCAT1 and CSQCKB, and any copies of those groups or of items from those groups, from your CSD. You must also delete the CKQQ TDQUEUE from group CSQCAT1. The definition for CKQQ is now supplied in the CICS CSD group DFHDCTG. If you do share your CSD with earlier CICS releases, ensure that CSQCAT1 and CSQCKB, and any copies of those groups or of their content, are not installed for CICS TS 4.1 or CICS TS 3.2. You must also delete the CKQQ TDQUEUE from group CSQCAT1. The definition for CKQQ is now supplied in the CICS CSD group DFHDCTG. For CICS TS releases earlier than CICS TS 3.2, install the CSQCAT1 and CSQCKB groups as part of a group list, after installing DFHLIST, to override group DFHMQ and correctly install the required definitions. Update the WebSphere MQ definitions for the dead-letter queue, default transmission queue, and CICS-WebSphere MQ adapter objects. You can use the sample CSQ4INYG, but you might need to change the initiation queue name to match the default initiation queue name in the MQINI resource definition for your CICS region. You can use this member in the CSQINP2 DD concatenation of the queue manager startup procedure, or you can use it as input to the COMMAND function of the CSQUTIL utility to issue the required DEFINE commands. Using the CSQUTIL utility is preferable because you do not then have to redefine these objects each time that you restart WebSphere MQ. The WebSphere MQ transport CICS can receive and send SOAP messages to WebSphere MQ (WMQ) using the WMQ transport, both in the role of service provider and service requester. Defining local queues in a service provider To use the WebSphere MQ transport in a service provider, you must define one or more local queues that store request messages until they are processed, and one trigger process that specifies the CICS transaction that will process the request messages. Defining local queues in a service requester When you use the WebSphere MQ transport for outbound requests in a service requester, you can specify in the URI for the target Web service that your responses should be returned on a predefined reply queue. If you do so, you must define each reply queue with a QLOCAL object. The URI for the WMQ transport When communication between the service requester and service provider uses WMQ, the URI of the target is in a form that identifies the target as a queue and includes information to specify how the request and response should be handled by WMQ. Configuring CICS to support persistent messages CICS provides support for sending persistent messages using the WMQ transport protocol to a Web service provider application that is deployed in a CICS region. Persistent message processing When a Web service request is received in a WMQ persistent message, CICS creates a unique BTS process with the process type DFHMQSOA. Data relating to the inbound request is captured in BTS data-containers that are associated with the process. |
So according to what you've said, you set up LE support for PL/I and you activated z/OS support for Unicode, along with installing the conversion image(s) you need -- this may not be needed depending upon which release of z/OS you're running. And you've installed the PIPELINE resource definition for your Web service. And if you used the CICS Web services assistant, you've added the PERFORM PIPELINE SCAN to your code. And you've defined your web service binding file with the WSBIND attribute of the WEBSERVICE resource. And you've used DFHWS2LS or DFHLS2WS with your WSDL. Remember, all this has to be completed before you can use CICS web services -- the link you quoted appears to assume that all this has already been done.
_________________
TANSTAAFL
The first rule of code reuse is that the code needs to be worth re-using.
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Donald Knuth